Solving Some of the Problems in Collaboration

1. ARL Aberdeen 22 April 2003 Solving Some of the Problems inCollaboration 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. Abstract • We address the challenges of building reliable collaboration environments and the opportunities to address this using modern Internet and Grid technologies. We examine two key building blocks; • namely a common dynamic messaging environment and • systematic use of Web Services including one to support session specification and control. • We present our prototype audio-video conferencing Web Service and messaging environment NaradaBrokering. We describe a core collaboration Web Service defined with an XML protocol XGSP subsuming the capabilities of H323, SIP and JXTA. • At this stage we have demonstrated various component ideas and are working on integrating them. We will discuss and hopefully demonstrate • a) Integration of Access Grid, desktop video and Polycom systems • b) Integration of SIP into XGSP with VOIP and Microsoft Messenger • c) Better software multicast support for Access Grid • d) Use of publish subscribe media servers supporting codec conversion and firewall tunneling. • e) Demonstration of codec conversion with integration of conferencing (H261) and streaming (RealVideo) clients • We hope to complete integration (“alpha” release) by July 2003. uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

3. Grid Computing: Making The Global Infrastructure a Reality • Fran Berman, Anthony J.G. Hey, Geoffrey Fox • ISBN: 0-470-85319-0 • Hardcover 1080 Pages • Publication March 2003 • http://www.grid2002.org • Chapters 18 22 and 43 discuss topics in todays seminar uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

4. Some Basic Observations/Goals • Web Services interact with messages • Everything (including applications like PowerPoint) will be a Web Service? • 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 for performance (QoS) and multicast • XML will be used for most interesting data and meta-data • Currently Grids are “just” Web Service approach to distributed information and computing systems uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

5. 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"

6. Message Passing on the Grid • 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"

7. 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"

8. Problems from Tango and all Others • Clients were unreliable – addressed by better windows and moving collaboration from Browser to an application • Networks were unreliable and firewalls are a problem • Not a lot of progress with QoS at network level • Some QoS problems are due to different collaboration streams interfering • Use application level QoS with highly robust managed messaging • Very hard to customize each application in “shared state event model” • Offer shared display • Convert Applications to Web Services • Many different standards H323, SIP, Access Grid, T120 … • Unify as single XML standard • Inconvenient to customize user interfaces • Use portlet technology supporting desktop and PDA clients uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

9. Portals and Web Services • Web Services allow us to build a component model (see CCA) for resources. • Each resource naturally has a user interface (which might be customized for user) • Web Service <--> Portlet • Natural to use a component model for portal building displayed web page from collection of portlets • So can customize each portlet and customize which portlets you want • Apache Jetspeed seems good open source technology supporting this model • Being used by NCSA and DoD HPCMO uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

10. WSDL W S Application orContent source R P Web Service WSRP Structure of a Portlet • Each Web Service naturally has a user interface specified as “just another port” • 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 portlet at same time Application as a WSGeneral Application Ports Interface with other Web Services PortalUser ProfileAggregateUI Fragments Client WSRP isWeb Services for Remote Portals1st Meeting OASIS March 18 2002 User Face ofWeb ServiceWSRP Ports define WS as a Portlet uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

11. HPCMO OKC Jetspeed Portal uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

12. NCSA Jetspeed Computing Portal uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

13. 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"

14. Session Server XGSP-based Control Media Servers Filters NaradaBrokering All Messaging Admire SIP H323 Access Grid Native XGSP XGSP MCU Architecture Use Multiple Media servers to scale to many codecs and many versions of audio/video mixing NB Scales asdistributed High Performance (RTP)and XML/SOAP and .. Gateways convert to uniform XGSP Messaging uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

15. 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"

16. 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"

17. Shared Event Collaboration • “True shared events” shares the events (like URL or PowerPoint file name/slide # ) that specify state of an application • However all collaboration is about sharing some sort of event • Audio/Video conferencing shares events specifying in compressed form audio or video • Shared display shares events corresponding to change in pixels of a framebuffer • Instant Messengers share updates to text message streams • Using Web services makes universal as exposes updates of all kinds as messages • Using NaradaBrokering makes messaging universal uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

18. Application with W3C DOM Structure as a Web Service Selected W3C DOM Semantic Events W3C DOM Raw(UI) Events W3C DOM User Interface Data Resource Facing Ports Application as a Web service Application Model Remaining W3C DOM Semantic Events MVCM: Model Control User FacingPorts View C:Control Events as Messages Rendering as Messages Application Viewand SelectedControl V: View uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

19. Application as a Web service From Collaboration As a WS To Collaborative Clients Master Client Rendering Events W3C DOM Events W3C DOM Events User Interface User Interface Application as a Web service From Collaboration As a WS Rendering Events From Master Participating Client uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

20. 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"

21. 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"

22. 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"

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

24. vic and RealVideo views of Single stream uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

25. vic and RealVideo views of multiple streams uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

26. Polycom view of multiple video streams uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

27. vic views of multiple video streams uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

28. Software in the XGSP MCU • Core Components are Open source • openh323 is basis of H323 Gateway • NIST SIP stack is basis of SIP Gateway • NaradaBrokering is open source messaging from Indiana • Java Media Framework basis of Media Servers • Can have proprietary modules such as • Anabas Shared Display • Instant Messengers • DIVX MPEG4 • HearMe VOIP ………… uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

29. Collaborative PDA • Extendable to more general universal access • Can implement filter either as an insertion in message stream or in batch mode where a Service subscribes to event stream (one collaborative application or “sharedlet”), filters it and reposts to a different stream • We developed first case with a special adaptor that is essentially a NaradaBrokering node that • Has added filters controlled by client profile • Has stripped down special purpose link protocol HHMS (Hand held message service) optimized for PDA • Currently implemented as MyProfessor for Windows CE iPAQ and Palm OS Cell-PDA combination • Have implemented shared display, SVG, Text chat, Instant Messenger (using Jabber) uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

30. Real-time Community Collaboration • Desktop PC, local wireless (802.11b) and the rest of the world (Sprint PCSVision as glimpse of next generation cell phones) • Reconcile different protocols, different display areas, different O/S and different network bandwidths Text Chat uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

31. Real-time Community Collaboration PowerPoint via “Shared Pixels” uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

32. Real-time Community Collaboration Scalable Vector Graphics (SVG) via “Shared Web Service” uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

33. SelectionView WSDL R U Customized View Application orContent source F F Filter I I O Control Channel O Selector Web Service Jetspeed Portal Customized View UserProfile Control Channel Render CustomizedUser-FacingPorts (NaradaBrokering)Event Service Universal Access With JetspeedWeb Services,MVC Model for applications Asynchronous Messaging uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

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

35. Status of XGSP Collaboration • We have demonstrated most key ideas but won’t have real “alpha” integrated system until June • Need to add RealAudio • Need to improve audio handling (silence suppression) in media server • Add other collaborative tools – many prototypes (shared display, shared PowerPoint, Games) • Could link at server (MCU) not client • Include Beihang tools like MPEG4 • Production version of PDA interface • Messaging (NaradaBroker) available today – full functionality by August • 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"

36. NaradaBrokering Publish/Subscribe Distributed Event/Message System • http://www.naradabrokering.org • “MQSeries/JMS” P/S applied to Collaboration, Grid, P2P(JXTA) • Supports UDP, TCP/IP, Firewalls (actual transport  user call) • Used in other projects: Collaboration, Portal and Handheld uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

37. 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 five 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 • Distributed XML data-base using P/S XPATH metaphor • Filtering for heterogeneous clients • Federation of multiple instances of Grid services as illustrated by JXTA peer-group linkage uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

38. 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"

39. 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"

40. 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"

41. 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"

42. 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"

43. 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"

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

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

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

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

48. 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 Administrative Interface uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

49. 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"

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