Collaborative Web Services and Peer-to-peer Grids

1. CTS03 Orlando 20 January 2003 Collaborative Web Services and Peer-to-peer Grids PTLIU Laboratory for Community Grids Geoffrey Fox Computer Science, Informatics, Physics Indiana University, Bloomington IN 47404 (Technology Officer, Anabas Corporation, San Francisco) http://grids.ucs.indiana.edu/ptliupages gcf@indiana.edu uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

2. Some Basic Observations/Goals • Technology Support for e-learning is one motivation • Need Synchronous and Asynchronous Resource Sharing • Can provide universal access using collaboration technology • Grids manage and share asynchronous resources in a rather centralized fashion • Peer-to-peer networks are “just like” Grids with different implementations of services like registration and look-up • Web Services interact with messages • Everything (including applications like PowerPoint) will be a WS? • Note few applications today have message-based I/O • Computers are fast and getting faster. One can afford many strategies that used to be unrealistic • All messages can be publish/subscribe • Software message routing • XML will be used for most interesting data and meta-data uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

3. Database Database Classic Grid Architecture Resources Content Access Composition Middle TierBrokers Service Providers Netsolve Security Collaboration Computing Middle Tier becomes Web Services Clients Users and Devices uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

4. Deductions • The system consists of a sea of message-based Services • Services inject and extract messages whose transport and manipulation is support by a logically distinct sea of brokers/routers • They support publish/subscribe,adaptive routing, filtering, workflow … • They separate logical and actual transport • These form a federated XML database and support asynchronous collaboration • These process real-time messages in about a millisecond and support synchronous collaboration • For collaboration, this implies one can: • Unify Collaboration Control (H323,SIP ..) as a Web Service • Provide single collaboration messaging environment (Audio/Video, shared display, text chat …) • Develop a generic support for Collaborative Web Services uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

5. Database Database Event/MessageBrokers Event/MessageBrokers Event/MessageBrokers Peer to Peer Grid Peers Service FacingWeb Service Interfaces Peers User FacingWeb Service Interfaces A democratic organization Peer to Peer Grid uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

6. So what are we doing of interest to CTS? • We co-edited a book on Grid Computing to be published April 2003 http://www.grid2002.org • We have designed and built a messaging infrastructure NaradaBrokering to support collaboration. Grids and P2P • We have shown interoperability between JXTA (Sun’s P2P environment), Java Message Service (JMS) and NaradaBrokering • We have deployed a classic (Placeware, Interwise, WebEx) synchronous collaboration environment using JMS or Narada for messaging (uses Anabas technology for shared applications) • We have illustrated collaborative pervasive/universal access by subscribing PDA’s and desktop’s to different filtered topics • We have prototyped audio-video conferencing as a web service • We are repackaging collaborative SVG as a Web service to illustrate (explore) how wonderful it will be when all applications are Collaborative Web services uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

7. WSDL Application orContent source Web Service Web Services in a Nutshell • Web Services codify a clear process for deploying distributed software components representing • Data and Information Sources (Sensors, Databases) • Computers • Application Software • Learning Services like “Submit Homework”, “Grade” • System services (OGSA Open Grid Service Architecture) • Distributed Message Passing Model • We should be in some process of dividing applications (including e-learning) into components and giving them an XML “skin” defining input and output ports (data, remote procedure calls) • WSDL Web Service Definition Language Ports: Messages to and fromother web services, resourcesor users uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

8. Different Web Service Organizations • Everything is a resource (distributed object)implemented as a Web Service, whether it be: • back end supercomputers and a petabyte dataset • Microsoft PowerPoint and this file • Web Services communicate by messages ….. • Web Services are “just distributed objects” with focus on (particular) XML specified input and output messages • Grids and Peer to Peer (P2P) networks can be integrated by building both in terms of Web Services with different (or in fact sometimes the same) implementations of core services such as registration, discovery, life-cycle, collaboration and event or message transport ….. • Gives a Peer-to-Peer Grid • Roughly but not completely consistent with OGSA (Open Grid Service Architecture) • Consistent with “rule”: build everything as a Web service uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

9. Education as a Web Service • “Learning Object” XML standards already exist from IMS/ADL http://www.adlnet.org – need to update architecture • Web Services for virtual university include: • Registration • Performance (grading) • Authoring of Curriculum • Online laboratories for real and virtual instruments • Homework submission • Quizzesof various types (multiple choice, random parameters) • Assessment data access and analysis • Synchronous Delivery of Curricula including Audio/Video Conferencing and other synchronous collaborative tools as Web Services • Scheduling of courses and mentoring sessions • Asynchronous access, data-mining and knowledge discovery • Learning Plan agents to guide students and teachers uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

10. Collaboration and Web Services • Collaboration has • Mechanism to set up members (people, devices) of a “collaborative sessions” • Shared generic tools such as text chat, white boards, audio-video conferencing • Shared applications such as Web Pages, PowerPoint, Visualization, maps, (medical) instruments …. • b) and c) are “just shared objects” where objects could be Web Services but rarely are at moment • We can port objects to Web Services and build a general approach for making Web services collaborative • a) is a “Service” which is set up in many different ways (H323 SIP JXTA are standards supported by multiple implementations) – we can make it a WS quite easily uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

11. Web Service Architecturefor Audio Video Conferencing uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

12. XGSP: Introduction Collaboration as a WS • Registration Method registration server with its alias name and current location • Session Command Method Membership Control Commands, Session Control Commands • Query Method discover various properties about the system • Session Channel Binding Method (Specific to A/V) bind the RTP channels of a client into the media server uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

13. XGSP: Example <SessionDes> <SessionName> PervasiveTech Seminar </SessionName> <SessionID> 1234567 </SessionID> <SessionCreator> Ahmet@indiana.edu </SessionCreator> <SessionInfo> this is a meeting on the XGSP </SessionInfo> <SessionPlace> Lobby Room </SessionPlace> <SessionTime> <StartTime> (EastTime) 10:00AM </StartTime> <EndTime> (EastTime) 12:00AM </EndTime> </SessionTime> <SessionURI> http://grids.ucs.indiana.edu/~ag </SessionURI> <SessionParticipants> <Participant> Wenjun@156.56.103.129 </Participant> <Participant> Hasan@156.56.103.27 </Participant> <Participant> Shrideeper@156.56.103.111 </Participant> </SessionParticipants> <ContactInfo> wewu@indiana.edu </ContactInfo> </SessionDes> uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

14. Linking Clientsor Servers Current ImplementationPolycom (H323) Access GridAdmire (Chinese system Similar to AG)and HearMe SIP VOIPClient Integration Server is Future ProjectLink Proprietary MCU’s Illustrated for SIP (HearMe)and Access Grid uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

15. System Summary • XGSP Specification stable • Will add native XGSP clients • H323 Gateway based on openh323 • JMF (Java Media Framework) used for Media Server but will replace JMF by NaradaBrokering for transport • Will describe use of NaradaBrokering for publish/subscribe Media Server • Will add filtering at server to allow codec choice as different topics in JMS/Narada • Initially offer streaming (RealNetworks) or conferencing (H261, MPEG4) • Add P2P (JXTA) interfaces • Add other shared applications using same XGSP control and Narada messaging • Collaboration with Admire Group at Beihang University • Aiming at 1000 students interacting with each other across Internet2 using A/V and Shared Display Summer 2003 (NOT broadcast Webcast) uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

16. XGSP MCU (Control) User Interface H323 Client (Polycom) in XGSP Session uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

17. Comparison with other approaches uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

18. Application as a WSGeneral Application PortsInterface with other WebServices WSDL W S Application orContent source R P Web Service User Face ofWeb ServiceWSRP Ports define WS as a Portlet Web Services as a Portlet • Each Web Service naturally has a user interface specified as “just another port” • Customizable for universal access • This gives each Web Service a Portlet view specified (in XML as always) by WSRP (Web services for Remote Portals) • So component model for resources “automatically” gives a component model for user interfaces • When you build your application, you define portletat same time WSRP isWeb Services for Remote Portals1st Meeting OASIS March 18 2002 uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

19. Object Viewer Object Display Object Object’ Object’’ Collaboration: Shared Display • Sharing can be done at any point on “object” or Web Service pipeline Shared Web Service SharedDisplay Shared Export Shared Event Master Shared Display shares framebuffer with eventscorresponding to changedpixels in master client. Event(Message)Service Object Display As long as pipeline uses messages, easy tomake collaborativeWindows framebuffers and in fact most applications do NOT expose a message based update interface Object Display uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

20. R R R U U U WSViewer WSDisplay F F F F F F I I I I I I WebService WebService WebService O O O O O O WS Viewer WS Display WS Viewer WSDisplay Shared Input Port (Replicated WS) Collaboration Collaboration as a WSSet up Session with XGSP Master Event(Message)Service OtherParticipants uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

21. Shared Output Port Collaboration WSDL R U Application orContent source F F WSViewer WSDisplay I I O O Web Service Collaboration as a WSSet up Session with XGSP Web Service Message Interceptor Master WS Viewer WS Display Text Chat Whiteboard Multiple masters Event(Message)Service OtherParticipants WS Viewer WSDisplay uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

22. NaradaBrokering • Based on a network of cooperating broker nodes • Cluster based architecture allows system to scale to arbitrary size • Originally designed to provide uniform software multicast to support real-time collaboration linked to publish-subscribe for asynchronous systems. • Now has four major core functions • Message transport (based on performance measurement) in heterogeneous multi-link fashion • General publish-subscribe including JMS & JXTA and support for RTP-based audio/video conferencing • Filtering for heterogeneous clients • Federation of multiple instances of Grid services uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

23. Role of Event/Message Brokers • We will use events and messages interchangeably • An event is a time stamped message • Our systems are built from clients, servers and “event brokers” • These are logical functions – a given computer can have one or more of these functions • In P2P networks, computers typically multifunction; in Grids one tends to have separate function computers • Event Brokers “just” provide message/event services; servers provide traditional distributed object services as Web services • There are functionalities that only depend on event itself and perhaps the data format; they do not depend on details of application and can be shared among several applications • NaradaBrokering is designed to provide these functionalities • MPI provided such functionalities for all parallel computing uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

24. Engineering Issues Addressedby Event / Messaging Service • Application level Quality of Service – e.g. give audio highest priority • Tunnel through firewalls & proxies • Filter messages to slow (collaborative/real-time) clients • Choose Hardware or Software multicast • Scaling of software multicast • Efficient calculation of destinations and routes. • Integrate synchronous and asynchronous collaboration with same messaging, control, archiving for all functions • Transparently replace single server JMS systems with a distributed solution. • Provides reliable inter-peer group messaging for JXTA • Open Source (high quality) messaging uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

25. Destination Source Matching Routing Filter workflow Web Service 1 Web Service 2 (Virtual)Queue WSDLPorts WSDLPorts Broker NaradaBrokering implements an Event Service • Filter is mapping to PDA or slow communication channel (universal access) – see our PDA adaptor • Workflow implements message process • Routing illustrated by JXTA and includes firewall • Destination-Source matching illustrated by JMS using Publish-Subscribe mechanism • These use Security model (being implemented) based on WS-Sec uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

26. Data base Narada Broker Network (P2P) Community For message/events service Broker Broker (P2P) Community Resource Hypercube topology for brokers? Tree for distance education with teacher at root Broker Broker Broker (P2P) Community Software multicast Broker (P2P) Community uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

27. NaradaBrokering Communication • Applications interface to NaradaBrokering through UserChannels which NB constructs as a set of links between NB Broker waystations which may need to be dynamically instantiated • UserChannels have publish/subscribe semantics with XML topics • Links implement a single conventional “data” protocol. • Interface to add new transport protocols within the Framework • Administrative channel negotiates the best available communication protocol for each link • Different links can have different underlying transport implementations • Implementations in the current release include support for TCP,UDP, Multicast, SSL and RTP. HTTP, HTTPS support will be available in Feb 2003 release. • Supports communication through proxies such as iPlanet, Netscape and Apache. • Supports communication through firewalls such as Microsoft ISA, Checkpoint. uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

28. FastLink FirewallHTTP B1 SatelliteUDP A Hand-HeldProtocol Software Multicast Dial-upFilter Performance/Routing in Message-based Architecture • In traveling from cities A to B (say 3 separate passengers), one chooses between and changes transport mechanism at waystations to optimize cost, time, comfort, scenic beauty … • Waystations are now NB brokers where one chooses transport protocol (individual or collective) • Able to choose between car, type of car, plane, train etc • Able to dynamically create waystations to cope with problems and acts as hubs for multicast messages • Knows about traffic jams and can assign the “HOV lane” B2 B3 uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

29. Note on Optimization • Note in parallel computing, couldn’t do much dynamic optimization as aiming at microsecond latency • Natural to use hardware routing • In Grid, time scales are different • 100 millisecond quite normal network latency • 30 millisecond typical packet time sensitivity (this is one audio or video frame) but even here can buffer 10-100 frames on client (conferencing to streaming) • 1 millisecond is time for a Java server to “think” • Jitter in latency (transit time) due to routing, processing (in NB) or packet loss recovery is important property • Grid needs and can tolerate significant dynamic optimization uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

30. Performance measurements are used by Links in Reconfiguring Connectivity between nodes Deciding underlying transport protocol Determining possible filtering Each node determines performance of links of which it is endpoint Individual node web services are aggregated as another Web Service Factors measured include Transit delays, bandwidth, Jitter, Receiving rates. Performance measurements are Spaced out at increasing intervals for healthy channels. Factors selectively measured for unhealthy channels. No repeated measurements of bandwidth for example. Injected into Narada network as XML events Narada Performance Web Service Probably should replace by a more sophisticated measurement package Administrative Interface uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

31. All measurements on commodity $1500 Linux PC • Sender/receiver/broker - (Pentium-3, 1 GHz, 256 MB RAM). 100 Mbps LAN. JDK-1.3, Red Hat Linux 7.3 uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

32. Sender/receiver/broker - (Pentium-3, 1 GHz, 256 MB RAM). 100 Mbps LAN. JDK-1.3, Red Hat Linux 7.3 uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

33. uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

34. uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

35. Jitter J = J + (|D(i-1, i)| - J)/16 uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

36. Narada supports UDP or TCP/IP uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

37. Each Stream 64kbps60 ms interval uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

38. uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

39. uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

40. Each Stream average Bandwidth 600kbps uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

41. uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

42. uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

43. uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

44. Narada/JMS and Collaboration • Collaboration involves sharing resources and synchronous collaboration involves coordinating a common view of a resource between multiple clients • Typically one client is “in charge” and others get initial and updated resource from this “master” • Specification of initial state of resource and its change are “just XML events” and we (Anabas and Indiana) have used first JMS and now NaradaBrokering to implement the transport of update events between collaborating clients • Update events include: • text you type into text chat or Instant Messenger • URL defining shared browser • Change in framebuffer for (most flexible) shared display • Microsoft events for shared PowerPoint (file replicated between clients) uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

45. Commercial CollaborationSystems Centra Anabas WebEx Placeware uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

46. Low Rate; Small Messages NaradaBrokering and JMS (Java Message Service) (commercial JMS) uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

47. Narada JXTA Event Request/Response Present if targeted atParticular peer NaradaBrokering and JXTA Narada-JXTA provides JXTA guaranteed long distance delivery uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

48. uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

49. uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

50. uri="http://www.naradabrokering.org" email="gcf@indiana.edu"