Peer-To-Peer Shared Components

1. Peer-To-Peer Shared Components Gerry Seidman IAM Consultingseidman@iamx.comhttp://iamx.com212-580-2700

2. What are we doing? • Banking/Finance • Commerce • Design • Publishing • Consulting • Education

3. What is the problem? • Dissemination of information • Text/images • PDF, HTML • Reports • CGI • Interactive • Data Entry / Analysis

4. Mechanisms of Information Presentation • Asynchronous • User works independently • Books, reports, Web, applications, videos, tapes • Synchronous • User works with one or more other person • In Person • Classroom • Consultant • Remote • Call to Call Center • Direct Call to Person • Conference Call • Video Conference • Instant Messaging

5. Relative Benefits • Asynchronous • Pros • User Paced • Cons • Onus is on user to find solutions to any problems • No Filter of information • Synchronous • Pros • Immediate answers • Cons • Scheduling • All material must be present • Ability to share material • May not be the right person

6. Application Sharing • Dedicated Communication Channel • Instant Message • Shared White Board • Non-Dedicated Applications • Web • Applications • Presentations

7. Methods of Application Sharing • Remote Web Control • Screen Replication over Sockets • PC-Anywhere • Java Based • Hand Coded interactivity • A couple of 100K lines of code you can do anything • Dynamic Sharing • Java Magic URL url = new URL("http://www.iamx.com"); AppletContext ac = myApplet.getAppletContext(); ac.showDocument(url);

8. Issues Behind Application Sharing • Difficulty of implementation • Extensibility • Performance • Quality of Feedback • The Voice Issue • None • Telephone • IP Telephony

9. Development Issues • Location of Partners • Data Model Location • Permission • Security

10. Digression on Communication • Messaging • Stream based • Packet Based (UDP) • Inappropriate for shared applications • Connected Sockets • Requires writing a server • Firewall Restrictions • HTTP • Connectionless • Batch mode • Piggyback on existing server • Little/No Security Restrictions

11. Direct Sockets in Java • Client Side • Server Side Socket s = new Socket(host, port); InputStream in = s.getInputStream(); OutputStream out = s.getOutputStream(); // process interaction, possibly multithreaded ServerSocket ss = new ServerSocket(port); for(;;) { Socket s = ss.accept(); InputStream in = s.getInputStream(); OutputStream out = s.getOutputStream(); // process interaction, probably multithreaded }

12. HTTP Interaction from Java URL url = new URL("http://www.iamx.com/findPartner"); URLConnection connect = url.openConnection(); connect.setDoOutput(true); connect.setDoInput(true); OutputStream out = connect.getOutputStream(); // send all information out.close(); InputStream in = connect.getInputStream(); // get entire result in.close();

13. Location of Partners • Generic Joining • No logic, maintain a list of users • Named Joining • Partner must be known • Partner must be available • Context Joining • User State determines partner

14. Context Joining • Session Based • Arbitrary amount of metric information • User ID • Location (in application) • State of Application • Matching algorithms • User Based • Current State • Past history • Server Side State warehousing • Inversion of Call Center • Control of Call Origination

15. Implementations of Joining Algorithm • HTTP using Servlet/CGI • Piggyback on existing server • Little/No security restrictions • Direct Sockets • Only if no HTTP option is available • You only join once, so performance isn't an issue

16. Java Shared Developer Toolkit • Messaging Framework • Channel Management • Session Managementhttp://java.sun.com/products/jsdt

17. Data Model Location • Issue: • Distributed Multithreading • VERY HARD PROBLEM!! • Implementation Options • Multiple Copies of Data Model • Single Master • Multi Master • Single View Data Model Access

18. Multiple Data Model Copies • Every partner has an identical copy of the data • Best solution for document based applications • i.e., where the model is an independent entity • Shared Word Processor • Allows for disconnect/reconnect strategies • Data model synchronization is application specific • Multi-User Diff for Word Processor Synching

19. Replicated Data Models: Single Master Mode • Only one partner can work on model at a time • Control is passed back and forth • All partners can view and notate • glass pane whiteboard, etc. • GUI for obtaining and reporting master mode ownership

20. Replicated Data Models: Multi-Master • Very hard to implement • Requires rollback and user feedback for lagged transaction clashes • Not worth the bother

21. << Demo of Shared Editor >>

22. Single Data Model Access • Only one view has actual access to the data • Note: Don't confuse single model with single model access • Two partners with concurrent access to a CORBA/RMI object is NOT single partner access • Model may be locally accessed by the partner or remote via RMI/CORBA/Sockets • Single master view into the model • Master View into Data • One (or more) Partner (Peer) Views • Views into Master View • GUI to GUI communication • View is on a Sub-Component level feedback • i.e. you see text field typing/selecting

23. << Demo of Shared Component >>

24. Java is Great • <Almost> • You still have to rely on library implementations • Reflection • Dynamically determine object types/structure • Introspection • Dynamically inspect data • Security controlled • private is still private • Accessor functions safer • Object Serialization • Copying objects over streams • Good for Models • Bad for GUI (Ironically) • Swing is not currently Serializable • Model would go with GUI through Object Graph

25. Dynamic Loading and Instantiation • Dynamic Loading of classes • Dynamic Instanciation • Polymorphic Usage Class cl = Class.forName("iam.talks.Foo"); Object x = cl.newInstance(); Component c = (Component) x;

26. Java GUI Model • Nested Container/Component Model • Traversable GUI tree Component comp = ... if (comp instanceof Container) { Container cont = (Container) comp; Component c[] = cont.getComponents(); for(int i=0; i < c.length; i++) { // do something with c[i]

27. Security and Firewalls • User access security is done at location time • This can be reinforced by passwords and encryption • Firewall restrictions • Outward connections no problem in Browser • Possibly a problem at the firewall • Solutions • Work behind the firewall • Open Firewall • Kluge a port 80 server • Frowned upon but works • HTTP Tunnelling • You would then need a periodic or manual refresh • Yuck, but it works

28. That’s All Folks Gerry Seidman Internet Access Methodsseidman@iamx.com212-580-2700 http://www.iam-there.comhttp://www.iamx.com