Скачать презентацию Grid-based Collaboration Minjun Wang Department of Electrical Engineering Скачать презентацию Grid-based Collaboration Minjun Wang Department of Electrical Engineering

d0d26e48da02a8d0b391890d236292ad.ppt

  • Количество слайдов: 54

Grid-based Collaboration Minjun Wang Department of Electrical Engineering and Computer Science Syracuse University mwang Grid-based Collaboration Minjun Wang Department of Electrical Engineering and Computer Science Syracuse University mwang [email protected] edu Advisor: Professor Geoffrey C. Fox Indiana University [email protected] edu

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

Motivation • Collaboration over the Internet is becoming more and more popular and important. 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 3 Buses

Background • Attractive to build Collaboration around Grid services with (SOAP) messages capturing “change 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 Narada. Brokering (Shrideep Pallickara, Syracuse Ph. D 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 Narada. Brokering but conclusions are not sensitive to this choice. User Change Grid Service Events Master Service Grid Service User Messaging 4 Collaborating Services/Users

Fundamental Research Issues • This approach “reduces” problem of building collaborative applications to that 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 Ph. D 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 5 (in thesis but not discussed in slides)

Practical Points and Performance • Our work verified results of earlier theses that Grid 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 6 earlier results (and note operational success of our examples)

Shared Event vs. Shared Display • We use Shared Event Model in this research 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 Tango. Interactive) • Shared Display has been implemented in Collaborative Grid formalism and is handled well by Narada. Brokering (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 7

Roles in Collaboration • Master, Participant, Administrator and Observer are typical roles • In 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 8 prototypes

A Collaboration Structure 9 A Collaboration Structure 9

Collaboration in Peer-to-peer Grid Systems • Grid Systems typically have identified “central” servers and 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 • P 2 P 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 P 2 P 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 10

Outline Part I. Motivation, Background, Research Issues, and Our Approach Part II. Experimental Systems 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 11

Collaborative Services • As described, Grid and web services do NOT change programming model 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 – Power. Point 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 12

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

Collaborative Power. Point Applications • Collaboration roles in terms of the Master client and Collaborative Power. Point 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) 14

The Mechanism for the Master Client to Capture Events 15 The Mechanism for the Master Client to Capture Events 15

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

The Events Available in Power. Point Interface 17 The Events Available in Power. Point Interface 17

The Events Missing in Power. Point Physical events Mouse. Over, Mouse. Clicked, Mouse. Double. The Events Missing in Power. Point Physical events Mouse. Over, Mouse. Clicked, Mouse. Double. Clicked, Key. Down, Key. Up, Key. Stroke, etc. Events about sounds Sound. Clip. Played, Sound. File. Played, etc. Events Animation. Clip. Played, about Movies. Played, animations Animation. File. Played, etc. and transitions 18

Lessons Learned • Events are not first-class, and very limited • Only in “EApplication” 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 19

Outline Part I. Motivation, Background, Research Issues, and Our Approach Part II. Experimental Systems 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 20

Collaborative IDL Applications • IDL is widely used in research, commerce, and education. • 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 Review. Plus 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 21

A Code Snippet from Collaborative IDL (Review. Plus) Applications 22 A Code Snippet from Collaborative IDL (Review. Plus) Applications 22

The Master Client • GUI building and managing and event handling • Master client 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 23

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

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

The Participant Client in Polling Structure • Critical section in interface of NB • 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 26

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

A Screen Shot from the Collaborative Review. Plus Applications 28 A Screen Shot from the Collaborative Review. Plus Applications 28

Advantages and Disadvantages The Notifying Structure • Advantages: – Not changing anything in the Advantages and Disadvantages 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). 29

Hop=2 is our case and these results from Pallickara illustrate performance that can be 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) 30

A Performance Test from the Collaborative Review. Plus Applications Time of bounce-back in milliseconds A Performance Test from the Collaborative Review. Plus 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) 31

Lessons Learned • Events are first-class • Amount of event generating can be tuned. 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. 32

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

Another General Approach for Collaboration in IDL (Embedded Collaboration Objects) • Keep user IDL 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. 34

Outline Part I. Motivation, Background, Research Issues, and Our Approach Part II. Experimental Systems 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 35

Collaborative Impress Applications Technologies for Universal Programming/Application • Universal Network Object (UNO) – a Collaborative Impress Applications Technologies for Universal Programming/Application • Universal Network Object (UNO) – a component technology. • Diverse Programming Environment – C++, 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 36

The Master Client • It sets up the remote bridge and takes control of 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. 37

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

Part of the Event Listener Interfaces and the Events 39 Part of the Event Listener Interfaces and the Events 39

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

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

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

Theoretical Framework for Collaboration • The Master client and Participant clients of each prototype 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. 43

The Finite Automaton • The standard five-tuple notation A = (Q, Σ, δ, q The Finite Automaton • The standard five-tuple notation A = (Q, Σ, δ, q 0, 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; • q 0 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 44 collaboration

Characteristics of the DFA for Collaboration Entities • The specialties in the set of 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 • “Open. File; Dir/filename”, “Goto; Certain. Slide#”, “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 Σ 45

A DFA Example in Collaborative Power. Point Applications A presentation file that has three A DFA Example in Collaborative Power. Point Applications A presentation file that has three slides 1, 2, & 3. • Q = {q 0, q 1, q 2, q 3, q 4}, where – q 0 is the state when the application is started; – q 1, q 2, q 3 are the states for slide 1, 2, and 3, respectively; – q 4 is the state when the application is ended. • Σ = {a 0, a 1, a 2, a 3, a 4, a 5, a 6}, with – – – – a 0 = “Openfile; C: /file 1. ppt” (open it), a 1 = “Goto; 1” (go to slide 1), a 2 = “Goto; 2” (go to slide 2), a 3 = “Goto; 3” (go to slide 3), a 4 = “Exit” (the application exits), a 5 = “Previous” (go to the previous slide), a 6 = “Next” (go to the next slide). • The start state is q 0. • The finite set of accepting states F = {q 4} 46

A DFA Example in Collaborative Power. Point Applications 47 A DFA Example in Collaborative Power. Point Applications 47

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

Conclusions q We have developed theoretical framework in terms of Deterministic Finite Automaton for Conclusions q We have developed theoretical framework in terms of Deterministic Finite Automaton for modeling collaboration. q We have developed three prototypes to investigate different approaches to programming services in shared event model for collaborative Grids q 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. q 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 49 component models for collaborative Grid services.

Contribution q. We have developed theoretical framework in terms of Deterministic Finite Automaton for Contribution q. We have developed theoretical framework in terms of Deterministic Finite Automaton for modeling collaboration. q. 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. 50

Future Work • New Categories – Microsoft Office suite: Access, Excel, Publisher, and Word. Future Work • New Categories – Microsoft Office suite: Access, Excel, Publisher, and Word. – Open. Office suite: Drawing, Spreadsheet, HTML Document, and Text Document. – IDL world: developed user applications – Investigate other programming and component models to see which behave like IDL. • New Requirements – from the General Atomics Affiliation, Inc. of USA • New Approaches to Design General Collaborative IDL Systems – Compiler Application – Embedded Collaboration Objects 51

Publications Conference Articles • • [1] Minjun Wang, Geoffrey Fox, and Marlon Pierce, “Collaboration Publications Conference Articles • • [1] Minjun Wang, Geoffrey Fox, and Marlon Pierce, “Collaboration Entities on Deterministic Finite Automata”, Proceedings of the 2006 International Symposium on Collaborative Technologies and Systems (CTS 2006), IEEE Computer Society, Las Vegas, Nevada, USA, May 14 -17, 2006, pp. 26 -37. [2] Minjun Wang, Geoffrey Fox, and Marlon Pierce, “Thin Client Collaboration Web Services”, Proceedings of the Advanced International Conference on Telecommunications and International Conference on Internet and Web Applications and Services (AICT/ICIW 2006), IEEE Computer Society, Guadeloupe, French Caribbean, February 23 -25, 2006, CD-ROM, Product Number E 2522, ISBN 0 -7695 -2522 -9, Library of Congress 2005937760. [3] Minjun Wang, Geoffrey Fox, and Marlon Pierce, “Instantiations of Shared Event Model in Grid-based Collaboration”, Proceedings of the 9 th World Multi-Conference on Systemics, Cybernetics and Informatics (WMSCI 2005), International Institute of Informatics and Systemics, Orlando, Florida, USA, July 10 -13, 2005, Volume III, pp. 11 -18. [4] Minjun Wang, Geoffrey Fox, and Marlon Pierce, “Grid-based Collaboration in Interactive Data Language Applications”, Proceedings of ITCC 2005 International Conference on Information Technology: Coding and Computing, IEEE Computer Society, Las Vegas, Nevada, USA, April 46, 2005, Volume I, pp. 335 -341. 52

Publications (2) Conference Articles • • • [5] Minjun Wang and Geoffrey Fox, “Design Publications (2) Conference Articles • • • [5] Minjun Wang and Geoffrey Fox, “Design of a Collaborative System” (for Impress of Open Office), Proceedings of the IASTED International Conference on Knowledge Sharing and Collaborative Engineering (KSCE 2004), ACTA Press, St. Thomas, US Virgin Islands, November 22 -24, 2004, pp. 192 -200. [6] Minjun Wang, Geoffrey Fox, and Shrideep Pallickara, “New Tools in Education”, Proceedings of the Seventh IASTED International Conference on Computers and Advanced Technology in Education (CATE 2004), ACTA Press, Kauai, Hawaii, USA, August 16 -18, 2004, pp. 218 -223. [7] Minjun Wang, Geoffrey C. Fox, and Shrideep Pallickara, “A Demonstration of Collaborative Web Services and Peer-to-peer Grids”, Proceedings of ITCC 2004 International Conference on Information Technology: Coding and Computing, IEEE Computer Society, Las Vegas, Nevada, USA, April 5 -7, 2004, Volume II, pp. 62 -67. [8] Geoffrey Fox, Hasan Bulut, Kangseok Kim, Sung-Hoon Ko, Sangmi Lee, Sangyoon Oh, Shrideep Pallickara, Xiaohong Qiu, Ahmet Uyar, Minjun Wang, and Wenjun Wu, “Collaborative Web Services and Peer-to-Peer Grids”, Proceedings of 2003 Collaborative Technologies Symposium (CTS’ 03), Orlando, USA, 2003. [9] Sangmi Lee, Geoffrey Fox, Sunghoon Ko, Minjun Wang, and Xiaohong Qiu, “Ubiquitous Access for Collaborative Information System Using SVG”, Proceedings of SVGopen conference, Zurich, Switzerland, July 2002. 53

Publications (3) Journal Articles • [1] Minjun Wang, Geoffrey Fox, and Shrideep Pallickara, “Demonstrations Publications (3) Journal Articles • [1] Minjun Wang, Geoffrey Fox, and Shrideep Pallickara, “Demonstrations of Collaborative Web Services and Peer-to-Peer Grids”, Journal of Digital Information Management, Digital Information Research Foundation, Adyar, Chennai, India, June 2004, Volume 2, Number 2, pp. 93 -96. (Special Issue of selected papers from the IEEE ITCC 2004) Technical Reports • • [1] Minjun Wang, “A Description of the Implementation of Collaborative Review. Plus”, Technical Report, July 19, 2005. [2] Minjun Wang, Geoffrey Fox, and Marlon Pierce, “General Collaboration Structures for Interactive Data Language Applications”, Technical Report, May 2005. Book Contribution • [1] Geoffrey C. Fox, Dennis Gannon, Sung-Hoon Ko, Sangmi Lee, Shrideep Pallickara, Marlon Pierce, Xiaohong Qiu, Xi Rao, Ahmet Uyar, Minjun Wang, and Wenjun Wu, “Peer-to-peer Grids”, Chapter 18 in Grid Computing: Making the Global Infrastructure a Reality, (Fran Berman, Geoffrey C. Fox, and Anthony J. G. Hey, editors, Chichester, West Sussex, England: John Wiley & Sons Ltd, 2003) pp. 471 -490. 54