Grid-based Collaboration

1. Grid-based Collaboration Minjun Wang Department of Electrical Engineering and Computer Science Syracuse University mwang03@syr.edu Advisor: Professor Geoffrey C. Fox Indiana University gcf@indiana.edu

2. Outline Part I. Motivation, Background, Research Issues, and Our Approach Part II. Experimental Systems Part III. Theoretical Framework Part IV. Conclusions and Future Work

3. Motivation • Collaboration over the Internet is becoming more and more popular and important. • Online conference, distance education, e-Learning, e-Science, e-Business, etc. • A major reason for low adoption of collaboration tools is network problems including dropped packets and firewalls • Further apart from shared display, often hard to share “events” needed to define changes needed to synchronize collaborating clients • Grids are built as Internet scale managed Web Services with “two-level programming model” • Services are conventional (Java, C++, Fortran, Python, Perl) programs wrapped in WSDL and exposing changes as messages • Services are composed with workflow (defined by industry standard BPEL) • Messages between services handled by Message Oriented Middleware style infrastructure generalizing Enterprise Service Buses

4. User User Grid Service ChangeEvents User Grid Service Messaging Grid Service MasterService Collaborating Services/Users Background • Attractive to build Collaboration around Grid services with (SOAP) messages capturing “change events” needed to relate collaborating clients • Then we need to handle events in a powerful fashion • This is role of NaradaBrokering (Shrideep Pallickara, Syracuse PhD 2001) which is Message Oriented Middleware that supports Web Service messaging, UDP and TCP, many event delivery models • Dominant Grid messaging system: downloaded 1000 times a year • JMS Java Message Service is the “Java world” equivalent • Mule is typical open source Enterprise Service Bus • Our work uses NaradaBrokering but conclusions are not sensitive to this choice.

5. Fundamental Research Issues • This approach “reduces” problem of building collaborative applications to that of building applications as Grid services • However essentially all applications are neither written as Web services nor do they have needed changes exposed as messages • These ideas have been investigated in two 2005 Syracuse PhD theses • Ahmet Uyar: Collaborative Audio-video conferencing • Xiaohong Qiu: Grid (Web) services as a model for desktop applications using Batik SVG browser as model • In this thesis we investigate models for building services and evaluate their effectiveness in producing collaborative Grid services • This is fundamental issue discussed in this thesis • We also need to develop a theoretical framework (Deterministic Finite Automata) and a general client service interaction model (in thesis but not discussed in slides)

6. Practical Points and Performance • Our work verified results of earlier theses that Grid messaging produced negligible overhead as its intrinsic overhead (2 millisecond today decreasing with Moore’s law) is an order of magnitude less than times relevant to Human perception (see Uyar thesis and 30 ms frame rate) • Early Web service technologies produce significant overhead but this is reduced in next generation (Axis 2) of web service container (Axis 2 from Apache is just released with about 5 ms overhead) • Other Indiana theses (Oh and Aydin) have explored overhead due to SOAP messages and shown it can be made small by transmitting “binary SOAP” i.e. messages compatible with SOAP Infoset but not using traditional angle bracket format • We can use this fast Infoset approach and transmit messages as text compatible with SOAP message semantics • Note Shared Event collaboration usually produces small messages and that is certainly true in examples in this thesis • Performance is not critical in this thesis and we just enhance earlier results (and note operational success of our examples)

7. Shared Event vs. Shared Display • We use Shared Event Model in this research • Reduce network traffic • Insure efficient utilizations of the computing capabilities. • Increase freedom in collaboration as to what event to or not to collaborate on • Investigate new application models compared to other work (such as TangoInteractive) • Shared Display has been implemented in Collaborative Grid formalism and is handled well by NaradaBrokering (only tested to 50 clients) as long as clients can support needed network bandwidth • Available in VNC and commercial systems • Can’t support dynamic applications well and failed for fusion physicists sharing IDL-based scientific visualizations

8. Roles in Collaboration • Master, Participant, Administrator and Observer are typical roles • In online gaming such as chess one exchanges master role between white and black • Virtual classroom typically has teacher as master and administrator able to give capabilities to students • Tokens specify role of clients • Token passing between the Master and Participant allow the interchange of their roles and is implemented as messages transmitted by Grid messaging system • Roles in Grid Collaboration very similar to those in traditional collaboration • XML syntax XGSP developed by Community Grids Laboratory to specify • We support simple master and non-master roles in our prototypes

9. A Collaboration Structure

10. Collaboration in Peer-to-peer Grid Systems • Grid Systems typically have identified “central” servers and “thin” peer clients. • Our current work can be deployed in such a way that the message broker in “central” and clients as the “thin” peers • P2P systems combine client and server (service) in the same machine. • The Master sends messages to Participants; any Participant can send messages to other Participants, with the message brokers in a P2P way (Future Work). • Peer-to-peer Grid Systems. • A hybrid of the above two; a Participant can get the messages (sent by the Master) from the “central” server, or from any other Participant, whichever is the closest (Future Work). • It appears that Skype Internet Audio-video conferencing has this architecture

11. Outline Part I. Motivation, Background, Research Issues, and Our Approach Part II. Experimental Systems Introduction Part III. Theoretical Framework Part IV. Conclusions and Future Work

12. Collaborative Services • As described, Grid and web services do NOT change programming model inside a service – they changes the interaction model between services for messaging and workflow • We wish to investigate programming models for a service that easily expose the needed change events to define the state movement of collaborating automata • Shared display exposes changes in framebuffer produced by an application • Another model (investigated in Qiu’s thesis) captures user input events (such as mouse events) and shares these • We look at sharing interactions defined by two different component models for desktop applications – PowerPoint and Impress • And we look at the (best from our research!) sharing of events in applications built using a language IDL where events built into language • Note ALL applications investigated are forms of visualization as this is a critical case which is important and where shared display often fails as it cannot sample framebuffer fast enough to capture dynamic scenes

13. Outline Part I. Motivation, Background, Research Issues, and Our Approach Part II. Experimental Systems Collaborative PowerPoint Part III. Theoretical Framework Part IV. Conclusions and Future Work

14. Collaborative PowerPoint Applications • Collaboration roles in terms of the Master client and the Participant client • Software model • Distributed Component Object Model (DCOM) • Identify events in the Master • Render event messages in the Participant • Achieve collaboration across Language boundaries • C/C++, Java, and Java Native Interface (JNI)

15. The Mechanism for the Master Client to Capture Events

16. The Mechanism for the Participating Client to Render Displays on Event Messages

17. The Events Available in PowerPoint Interface

18. The Events Missing in PowerPoint

19. Lessons Learned • Events are not first-class, and very limited • Only in “EApplication” IDispatch interface • Difficult to make the application collaborative • DCOM, JNI, Events captured in hexadecimal format • Can not collaborate on all events

20. Outline Part I. Motivation, Background, Research Issues, and Our Approach Part II. Experimental Systems Collaborative IDL Part III. Theoretical Framework Part IV. Conclusions and Future Work

21. Collaborative IDL Applications • IDL is widely used in research, commerce, and education. • Engineering, medical physics, astronomical and space science, and earth science. • Complete and proper definitions of event structures in IDL • Structures, levels, configurations • Elegant mechanisms of widget programming of IDL • Widgets in IDL correspond to GUIs in Java, such as buttons, sliders • Experiments in different Event Distribution Modes • Notifying structure vs. Polling Structure • Success in making real-life IDL applications collaborative • Collaboration experience on ReviewPlus package from General Atomics of U.S.A • System currently being evaluated for deployment in fusion research • Small company RSI in Colorado that markets IDL interested in (a production version of) our research

22. A Code Snippet from Collaborative IDL (ReviewPlus) Applications

23. The Master Client • GUI building and managing and event handling • Master client connects and sends event messages to the message broker via the IDL-Java bridge

24. The Participant Client in Notifying Structure • Callable IDL and JNI • Native functions (IDL routines) in a shared library

25. Generating of a Shared Library • A C program calls the IDL routines directly through Callable IDL technology • A shared library (libCallableIDL.so) is generated from the C program.

26. The Participant Client in Polling Structure • Critical section in interface of NB • The client polling the event flag and getting event messages • The client rendering the displays on the message

27. A Sample of Event Structures Used in IDL Widget Programming

28. A Screen Shot from the Collaborative ReviewPlus Applications

29. The Notifying Structure Advantages: Not changing anything in the IDL and the NB systems. Development is in the collaborative applications. Disadvantages: complicated and inconsistent in the code shapes time and efforts cost is high It is difficult to develop The Polling Structure Advantages: Simple Practical and feasible for large IDL applications to be collaborative Prevents data loss Disadvantages: Have to change the underlying systems (e.g., an interface of NB). Advantages and Disadvantages

30. Hop=2 is our case and these results from Pallickara illustrate performance that can be gotten if NB placed near IDL (at GA in our case)

31. A Performance Test from the Collaborative ReviewPlus Applications Time of bounce-back in milliseconds between the Master Client (San Diego, CA) and the NB (Bloomington, IN) • Mean: 130.72 (milliseconds) • Standard Deviation: 10.18 (milliseconds) • Standard Error: 1.41 (milliseconds)

32. Lessons Learned • Events are first-class • Amount of event generating can be tuned. • e.g. (1) The keyword DRAG for function WIDGET_SLIDER; (2) Keywords All_Event and Return_Event for text field widget. • Elegant mechanisms of widget programming contributes to the success in collaboration.

33. A General Approach for Collaboration in IDL (Compiler)

34. Another General Approach for Collaboration in IDL(Embedded Collaboration Objects) • Keep user IDL applications “untouched” (or almost “untouched”) • Accommodate the IDL system routines and libraries to satisfy the collaboration needs. • The IDL system library routine “XMANAGER.pro” • provides the main event loop and management of widgets. • not called much; usually once a widget program. • It is possible for us to deal with all the event handling and processing in this routine and all other related system routines to achieve collaboration. • Make a version for the Master client (XMANAGER_MASTER.pro) and a version for the Participant client (XMANAGER_PARTICIPANT.pro). • Deploy them to the end user IDL applications, replace “XMANAGER.pro” with “XMANAGER_MASTER.pro” on the Master and with “XMANAGER_PARTICIPANT.pro” on the Participant.

35. Outline Part I. Motivation, Background, Research Issues, and Our Approach Part II. Experimental Systems Collaborative Impress Part III. Theoretical Framework Part IV. Conclusions and Future Work

36. Collaborative Impress Applications Technologies for Universal Programming/Application • Universal Network Object (UNO) • a component technology. • Diverse Programming Environment • C++, Java, Java Script, Visual Basic, VBScript, and Delphi; on platforms such as UNIX, Linux, and Windows. • Fine-grained Application Programming Interfaces (API) • Open Office defines a comprehensive specification describing its programmable features, and it is fine-grained. • Frame-Controller-Model (FCM) Paradigm • The Model is the document object • The controller is the screen interaction with the model • The frame is the controller-window linkage

37. The Master Client • It sets up the remote bridge and takes control of the programming features of Office via FCM paradigm • It registers listeners at the remote bridge to listen to events fired at the Office server.

38. The Participating Client • Creates a remote bridge • Gets control of the FCM to call functionality in controlling the rendering process.

39. Part of the Event Listener Interfaces and the Events

40. Environments and Displays of the Master and Participant at a Collaboration Step

41. Lessons Learned • Similar problems to those found in collaborative PowerPoint • Events are not first class. Events available depends on the work of the OpenOffice developers • e.g., the Impress “slide show” interfaces were underdeveloped • The labor in making the application collaborative is high

42. Outline Part I. Motivation, Background, Research Issues, and Our Approach Part II. Experimental Systems Part III. Theoretical Framework Part IV. Conclusions and Future Work

43. Theoretical Framework for Collaboration • The Master client and Participant clients of each prototype are collaboration entities. • The collaboration entities of a type play different roles, and they are finite automaton-based in a collaboration session. • The Master and Participant collaboration entities have the same logic as to the state transitions on events, and get to the same state at the end of the process of each event.

44. The Finite Automaton • The standard five-tuple notation A = (Q, Σ, δ, q0, F), where • A is the name of the automaton; • Q is the finite set of states of the automaton; • Σ is the finite set of input symbols; • q0 is the start state; • F is the finite set of final or accepting states, which is a subset of Q • δ is the transition function, which takes as parameters a state from Q and a symbol from Σ, and returns a state in Q for Deterministic Finite Automata (DFA), or a set of states from Q for Nondeterministic Finite Automaton (NFA). • Deterministic Finite Automata (DFA) are suitable for modeling the collaboration entities in a shared event collaboration session. • The meaning of this modeling: • simple, clear, and consistent picture • see through the differences between the entities • see the important roles of events and the shared event model in collaboration

45. Characteristics of the DFA for Collaboration Entities • The specialties in the set of input symbols Σ • Traditionally, the symbols in Σ are alphabets, digits, or any printable ASCII characters (e.g., a, b, c, 1, 2, 3, %, $, &). • In our modeling, we define the symbols (or units) in Σ to be event messages, which are independent text strings • “OpenFile;Dir/filename”, “Goto;CertainSlide#”, “Previous”, “Next” • “{Widget_Base;ID:10;TOP:8;HANDLER:10;X:123;Y:456}” • This is to use semantically complete event messages as the basic units in Σ

46. A DFA Example in Collaborative PowerPoint Applications A presentation file that has three slides 1, 2, & 3. • Q = {q0, q1, q2, q3, q4}, where • q0 is the state when the application is started; • q1, q2, q3 are the states for slide 1, 2, and 3, respectively; • q4 is the state when the application is ended. • Σ = {a0, a1, a2, a3, a4, a5, a6}, with • a0 = “Openfile;C:/file1.ppt” (open it), • a1 = “Goto;1” (go to slide 1), • a2 = “Goto;2” (go to slide 2), • a3 = “Goto;3” (go to slide 3), • a4 = “Exit” (the application exits), • a5 = “Previous” (go to the previous slide), • a6 = “Next” (go to the next slide). • The start state is q0. • The finite set of accepting states F = {q4}

47. A DFA Example in Collaborative PowerPoint Applications

48. Outline Part I. Motivation, Background, Research Issues, and Our Approach Part II. Experimental Systems Part III. Theoretical Framework Part IV. Conclusions and Future Work

49. Conclusions • We have developed the theoretical framework in terms of Deterministic Finite Automaton for modeling collaboration. • We have developed three prototypes to investigate different approaches to programming services in shared event model for collaborative Grids • It is important to make useful standalone applications collaborate universally, and find the efficient and elegant ways to make them collaborative, with regard to architectures, event structures, and mechanisms of widget programming. • We have succeeded in three different programming models but conclude that languages like IDL, where the complete and proper definitions of event structures are supplied and elegant mechanisms of widget programming are guaranteed, are more suitable than traditional component models for collaborative Grid services.

50. Contribution • We have developed the theoretical framework in terms of Deterministic Finite Automaton for modeling collaboration. • We have made useful standalone applications collaborate universally, have found the efficient and elegant ways to make them collaborative, and have investigated different approaches to programming services in shared event model for collaborative Grids.