1. 1 Grids for Real-time and Streaming Applications TIWDC 2005 CNIT Tyrrhenian International Workshop on Digital Communications July 4-6 2005 Geoffrey Fox Computer Science, Informatics, Physics Pervasive Technology Laboratories Indiana University Bloomington IN 47401 http://grids.ucs.indiana.edu/ptliupages/presentations/cnitjuly5-05.ppt gcf@indiana.edu http://www.infomall.org

2. 2 Summary This presentation describes how Grids can support sensors or instruments with high performance streaming information Grids, Web Services and P2P Networks are all though of as services connected by messages We describe the WS-* specifications and their role We illustrate with three projects from the Community Grids Laboratory NaradaBrokering: Software Overlay Network CrisisGrid and SERVOGrid: GIS and Sensor Grids GlobalMMCS: Service oriented collaboration Grid

3. 3 Internet Scale Distributed Services Grids use Internet technology and are distinguished by managing or organizing sets of network connected resources Classic Web allows independent one-to-one access to individual resources Grids integrate together and manage multiple Internet- connected resources: People, Sensors, computers, data systems Organization can be explicit as in TeraGrid which federates many supercomputers; Deep Web Technologies Information Retrieval Grid which federates multiple data resources; CrisisGrid which federates first responders, commanders, sensors, GIS, (Tsunami) simulations, science/public data Organization can be implicit as in Internet resources such as curated databases and simulation resources that “harmonize a community”

4. 4 Different Visions of the Grid Grid just refers to the technologies Or Grids represent the full system/Applications In the USA, DoD’s vision of Network Centric Computing can be considered a Grid (linking sensors, warfighters, commanders, backend resources) and they are building the GIG (Global Information Grid) Utility Computing or X-on-demand (X=data, computer..) is major computer Industry interest in Grids and this is key part of enterprise or campus Grids e-Science or Cyberinfrastructure are virtual organization Grids supporting global distributed science (note sensors, instruments are people are all distributed) Skype (Kazaa) VOIP system is a Peer-to-peer Grid (and VRVS/GlobalMMCS like Internet A/V conferencing are Collaboration Grids) Commercial 3G Cell-phones and ad-hoc network initiatives are forming mobile Grids

5. 5 e-moreorlessanything and the Grid e-Business captures an emerging view of corporations as dynamic virtual organizations linking employees, customers and stakeholders across the world. The growing use of outsourcing is one example e-Science is the similar vision for scientific research with international participation in large accelerators, satellites or distributed gene analyses. The Grid integrates the best of the Web, traditional enterprise software, high performance computing and Peer- to-peer systems to provide the information technology e- infrastructure for e-moreorlessanything. A deluge of data of unprecedented and inevitable size must be managed and understood. People, computers, data and instruments must be linked. On demand assignment of experts, computers, networks and storage resources must be supported

6. 6 Some Important Styles of Grids Computational Grids were origin of concepts and link computers across the globe – high latency stops this from being used as parallel machine Typically Compute/File Grids where information (messages) exchanged by writing and reading files Knowledge and Information Grids link sensors and information repositories as in Virtual Observatories or BioInformatics Education Grids link teachers, learners, parents as a VO with learning tools, distant lectures etc. e-Science Grids link multidisciplinary researchers across laboratories and universities Community Grids focus on Grids involving large numbers of peers rather than focusing on linking major resources – links Grid and Peer-to-peer network concepts Semantic Grid links Grid, and AI community with Semantic web (ontology/meta-data enriched resources) and Agent concepts Collaboration Grids support the linkage of multiple people and electronic resources (often peer-to-peer architecture)

7. 7 Information/Knowledge Grids Distributed (10’s to 1000’s) of data sources (instruments, file systems, curated databases …) Data Deluge: 1 (now) to 100’s petabytes/year (2012) Moore’s law for Sensors Possible filters assigned dynamically (on-demand) Run image processing algorithm on telescope image Run Gene sequencing algorithm on compiled data Needs decision support front end with “what-if” simulations Metadata (provenance) critical to annotate data Integrate across experiments as in multi-wavelength astronomy Data Deluge comes from pixels/year available

8. 8 Database Analysis and Visualization Portal Repositories Federated Databases Data Filter Services Field Trip Data Streaming Data Sensors ? Discovery Services SERVOGrid Research Simulations ResearchEducation Customization Services From Research to Education Education Grid Computer Farm Grid of Grids: Research Grid and Education Grid GIS Grid Sensor Grid Database Grid Compute Grid

9. 9 Virtual Observatory Astronomy Grid Integrate Experiments RadioFar-InfraredVisible Visible + X-ray Dust Map Galaxy Density Map

10. 10 HPC Simulation Data Filter Data Filter Data Filter Data Filter Data Filter Distributed Filters massage data For simulation Other Grid and Web Services Analysis Control Visualize SERVOGrid (Complexity) Computing Model Grid OGSA-DAI Grid Services This Type of Grid integrates with Parallel computing Multiple HPC facilities but only use one at a time Many simultaneous data sources and sinks Grid Data Assimilation Databases and/or Sensors

11. 11 Sources of Grid Technology Grids support distributed collaboratories or virtual organizations integrating concepts from The Web Agents Distributed Objects (CORBA Java/Jini COM) Globus, Legion, Condor, NetSolve, Ninf and other High Performance Computing activities Peer-to-peer Networks With perhaps the Web and P2P networks being the most important for “Information Grids” and Globus for “Compute/File Grids”

12. 12 The Essence of Grid Technology? We will start from the Web view and assert that basic paradigm is Meta-data rich Web Services communicating via messages These have some basic support from some runtime such as.NET, Jini (pure Java), Apache Tomcat+Axis (Web Service toolkit), Enterprise JavaBeans, WebSphere (IBM) or GT3/4 (Globus Toolkit 3/4) These are the distributed equivalent of operating system functions as in UNIX Shell Called Hosting Environment or platform W3C standard WSDL defines IDL (Interface standard) for Web Services

13. 13 A typical Web Service In principle, services can be in any language (Fortran.. Java.. Perl.. Python) and the interfaces can be method calls, Java RMI Messages, CGI Web invocations, totally compiled away (inlining) The simplest implementations involve XML messages (SOAP) and programs written in net friendly languages like Java and Python Payment Credit Card Warehouse Shipping control WSDL interfaces SecurityCatalog Portal Service Web Services

14. 14 Classic Grid Architecture Database Netsolve Computing Security Collaboration Composition Content Access Resources ClientsUsers and Devices Middle Tier Brokers Service Providers Middle Tier becomes Web Services

15. 15 Peer to Peer Grid Database Peers Peer to Peer GridA democratic organization User Facing Web Service Interfaces Service Facing Web Service Interfaces Event/ Message Brokers

16. 16 What is Happening? Grid ideas are being developed in (at least) four communities Web Service – W3C, OASIS, (DMTF) Grid Forum (High Performance Computing, e-Science) Enterprise Grid Alliance (Commercial “Grid Forum” with a near term focus) Service Standards are being debated Grid Operational Infrastructure is being deployed Grid Architecture and core software being developed Apache has several important projects as do academia; large and small companies Particular System Services are being developed “centrally” – OGSA framework for this in GGF; WS-* for OASIS/W3C/Microsoft-IBM Lots of fields are setting domain specific standards and building domain specific services USA started Grids but now Europe is probably in the lead and Asia will soon catch USA if momentum (roughly zero for USA) continues

17. 17 Technical Activities of Note Look at different styles of Grids such as Autonomic (Robust Reliable Resilient) New Grid architectures hard due to investment required Program the Grid – Workflow Access the Grid – Portals, Grid Computing Environments Critical Services Such as Security – build message based not connection based Notification – event services Metadata – Use Semantic Web, provenance Fabric and Service Management Databases and repositories – instruments, sensors Computing – Submit job, scheduling, distributed file systems Visualization, Computational Steering Network performance Low Level WS-* High Level e.g. OGSA

18. 18 Web services Web Services build loosely-coupled, distributed applications, (wrapping existing codes and databases) based on the SOA (service oriented architecture) principles. Web Services interact by exchanging messages in SOAP format The contracts for the message exchanges that implement those interactions are described via WSDL interfaces.

19. 19 Philosophy of Web Service Grids Much of Distributed Computing was built by natural extensions of computing models developed for sequential machines This leads to the distributed object (DO) model represented by Java and CORBA RPC (Remote Procedure Call) or RMI (Remote Method Invocation) for Java Key people think this is not a good idea as it scales badly and ties distributed entities together too tightly Distributed Objects Replaced by Services Note CORBA was considered too complicated in both organization and proposed infrastructure and Java was considered as “tightly coupled to Sun” So there were other reasons to discard Thus replace distributed objects by services connected by “one-way” messages and not by request-response messages

20. 20 SOAP Message Structure I SOAP Message consists of headers and a body Headers could be for Addressing, WSRM, Security, Eventing etc. Headers are processed by handlers or filters controlled by container as message enters or leaves a service Body processed by Service itself The header processing defines the “Web Service Distributed Operating System” Containers queue messages; control processing of headers and offer convenient (for particular languages) service interfaces Handlers are really the core Operating system services as they receive and give back messages like services; they just process and perhaps modify different elements of SOAP Message H1H4H3H2Body F1F2F3 F4 Service Container Handlers Container Workflow

21. 21 Merging the OSI Levels All messages pass through multiple operating systems and each O/S thinks of message as a header and a body Important message processing is done at Network Client (UNIX, Windows, J2ME etc) Web Service Header Application EACH is < 1ms (except for small sensor clients and except for complex security) But network transmission time is often 100ms or worse Thus no performance reason not to mix up places processing done IP TCP SOAP App

22. 22 Consequences of Rule of the Millisecond Useful to remember critical time scales 1) 0.000001 ms – CPU does a calculation 2a) 0.001 to 0.01 ms – Parallel Computing MPI latency 2b) 0.001 to 0.01 ms – Overhead of a Method Call 3) 1 ms – wake-up a thread or process (do simple things on a PC) 4) 10 to 1000 ms – Internet delay 2a), 4) implies geographically distributed metacomputing can’t in general compete with parallel systems 3) << 4) implies a software overlay network is possible without significant overhead We need to explain why it adds value of course! 2b) versus 3) and 4) describes regions where method and message based programming paradigms important

23. 23 Plethora of Web Service Standards Java is very powerful partly due to its many “frameworks” that generalize libraries e.g. Java Media Framework JMF Java Database Connectivity JDBC Web Services have a correspondingly collections of specifications that represent critical features of its distributed operating systems for About 60 WS-* specifications introduced in last 2-3 years These are low level with higher level standards such as access database (OGSA-DAI) or “Submit a job” built on top of these Many battles both between standard bodies and between companies as each tries to set standards they consider best; thus there are multiple standards for many of key Web Service functionalities Microsoft a key player and stands to benefit as Web Services open up enterprise software space to all participants e.g. MQSeries (IBM) and Tibco have to change their messaging systems to support new open standards

24. 24 WS-I Interoperability Critical underpinning of Grids and Web Services is the gradually growing set of specifications in the Web Service Interoperability Profiles Web Services Interoperability (WS-I) Interoperability Profile 1.0a." http://www.ws-i.org. gives us XSD, WSDL1.1, SOAP1.1, UDDI in basic profile and parts of WS-Security in their first security profile.http://www.ws-i.org We imagine the “60 Specifications” being checked out and evolved in the cauldron of the real world and occasionally best practice identifies a new specification to be added to WS-I which gradually increases in scope Note only 4.5 out of 60 specifications have “made it” in this definition

25. 25 Bit level Internet (OSI Stack) Layered Architecture for Web Services and Grids Base Hosting Environment Protocol HTTP FTP DNS … Presentation XDR … Session SSH … Transport TCP UDP … Network IP … Data Link / Physical Service Internet Application Specific Grids Generally Useful Services and Grids Workflow WSFL/BPEL Service Management (“Context etc.”) Service Discovery (UDDI) / Information Service Internet Transport  Protocol Service Interfaces WSDL Service Context Higher Level Services

26. WS-* implies the Service Internet We have the classic (CISCO, Juniper ….) Internet routing the flood of ordinary packets in OSI stack architecture Web Services build the “Service Internet” or IOI (Internet on Internet) with Routing via WS-Addressing not IP header Fault Tolerance (WS-RM not TCP) Security (WS-Security/SecureConversation not IPSec/SSL) Data Transmission by WS-Transfer not HTTP Information Services (UDDI/WS-Context not DNS/Configuration files) At message/web service level and not packet/IP address level Software-based Service Internet possible as computers “fast” Familiar from Peer-to-peer networks and built as a software overlay network defining Grid (analogy is VPN) SOAP Header contains all information needed for the “Service Internet” (Grid Operating System) with SOAP Body containing information for Grid application service

27. 27 What is a Simple Service? Take any system – it has multiple functionalities We can implement each functionality as an independent distributed service Or we can bundle multiple functionalities in a single service Whether functionality is an independent service or one of many method calls into a “glob of software”, we can always make them as Web services by converting interface to WSDL Simple services are gotten by taking functionalities and making as small as possible subject to “rule of millisecond” Distributed services incur messaging overhead of one (local) to 100’s (far apart) of milliseconds to use message rather than method call Use scripting or compiled integration of functionalities ONLY when require <1 millisecond interaction latency Apache web site has many (pre Web Service) projects that are multiple functionalities presented as (Java) globs and NOT (Java) Simple Services Makes it hard to integrate “globs” sharing common security, user profile, file access.. services

28. 28 Grids of Grids of Simple Services Link via methods  messages  streams Services and Grids are linked by messages Internally to service, functionalities are linked by methods A simple service is the smallest Grid We are familiar with method-linked hierarchy Lines of Code  Methods  Objects  Programs  Packages Overlay and Compose Grids of Grids MethodsServicesComponent Grids CPUsClusters Compute Resource Grids MPPs Databases Federated Databases SensorSensor Nets Data Resource Grids

29. 29 Component Grids So we build collections of Web Services which we package as component Grids Visualization Grid Sensor Grid Management Grid Utility Computing Grid Collaboration Grid Earthquake Simulation Grid Control Room Grid Crisis Management Grid Intelligence Data-mining Grid We build bigger Grids by composing component Grids using the Service Internet

30. 30 Critical Infrastructure (CI) Grids built as Grids of Grids Gas Services and Filters Physical Network RegistryMetadata Flood Services and Filters Flood CIGrid Gas CIGrid … Electricity CIGrid … Data Access/Storage SecurityWorkflowNotificationMessaging Portals Visualization GridCollaboration Grid Sensor GridCompute GridGIS Grid Core Grid Services

31. 31 The WS-* Infrastructure Core Grid Services build on and/or extend the 60 or so WS-* Infrastructure specifications which define Container Model, XML, WSDL … Service Internet ( (Reliable) Messaging, Addressing) including extensions for high performance transport and representation. This is natural basis for streaming applications Notification (WS-Notification and WS-Eventing) Workflow and Transactions Security Service Discovery Metadata and State including lifetime Management (service interactions) Policy, Agreements Portals and User Interfaces

32. 32 Role of WS-* specifications Service Internet and Notification define a distributed publish-subscribe software overlay network SOAP Intermediaries give you needed routing Workflow specifies how the services (sensors and their aggregators and transformers) are linked together WS-Security gives you message based security Service discovery, metadata and state define several types of metadata catalogs (MDS, UDDI, Chord …) Management defines the protocol and information exchange between services or between a service and a proxy Intel will support plug & play by putting WS-Management on every chip WS-Policy allows one to specify HOW to do things WSRP specifies how users interact with services

33. 33 Core (Commonly Used) Grid Services (OGSA) Higher level discovery and metadata – Registries, catalogs, Semantic Grid, Provenance Higher level security with fine grain authorization, session level security etc. Higher level execution services building on workflow and including job management for simulations Infrastructure services giving common interfaces to heterogeneous resource such as storage and computers Data and Information services including federated databases and use of CIM Self and distributed (resource) management for autonomic features, configuration Collaboration, Sensors, Visualization, GIS Not in OGSA

34. 34 3 Real-time Grid Projects in Community Grids Laboratory htpp://www.naradabrokering.org provides Web service (and JMS) compliant distributed publish-subscribe messaging (software overlay network) htpp://www.naradabrokering.org htpp://www.globlmmcs.org is a service oriented (Grid) collaboration environment (audio-video conferencing) including mobile clients htpp://www.globlmmcs.org http://www.crisisgrid.org is an OGC (open geospatial consortium) Geographical Information System (GIS) compliant GIS and Sensor Grid http://www.crisisgrid.org The work is still in progress but NaradaBrokering is quite mature All software is open source and freely available

35. 35 NaradaBrokering Stream NB supports messages and streams NB role for Grid is Similar to MPI role for MPP Queues

36. 36 Multiple protocol transport support In publish-subscribe Paradigm with different Protocols on each link Transport protocols supported include TCP, Parallel TCP streams, UDP, Multicast, SSL, HTTP and HTTPS. Communications through authenticating proxies/firewalls & NATs. Network QoS based Routing Allows Highest performance transport Subscription FormatsSubscription can be Strings, Integers, XPath queries, Regular Expressions, SQL and tag=value pairs. Reliable delivery Robust and exactly-once delivery in presence of failures Ordered delivery Producer Order and Total Order over a message type. Time Ordered delivery using Grid-wide NTP based absolute time Recovery and Replay Recovery from failures and disconnects. Replay of events/messages at any time. Buffering services. Security Message-level WS-Security compatible security Message Payload options Compression and Decompression of payloads Fragmentation and Coalescing of payloads Messaging Related Compliance Java Message Service ( JMS ) 1.0.2b compliant Support for routing P2P JXTA interactions. Grid Feature SupportNaradaBrokering enhanced Grid-FTP. Bridge to Globus GT3. Web Services supportedImplementations of WS-ReliableMessaging, WS-Reliability and WS-Eventing. Traditional NaradaBrokering Features

37. 37 Features for mid 2005 Releases Production implementations of WS-Eventing, WS-RM and WS-Reliability. WS-Notification when specification agreed SOAP message support and NaradaBrokers viewed as SOAP Intermediaries Active replay support: Pause and Replay live streams. Stream Linkage: can link permanently multiple streams – using in annotating real-time video streams Replicated storage support for fault tolerance and resiliency to storage failures. Management: HPSearch Scripting Interface to streams and services Broker Discovery: Locate appropriate brokers

38. 38 hop-3 0 1 2 3 4 5 6 7 8 9 1001000 Transit Delay (Milliseconds) Message Payload Size (Bytes) Mean transit delay for message samples in NaradaBrokering: Different communication hops hop-2 hop-5 hop-7 Pentium-3, 1GHz, 256 MB RAM 100 Mbps LAN JRE 1.3 Linux

39. 39

40. 40 Possible NaradaBrokering Futures Support for replicated storages within the system. In a system with N replicas the scheme can sustain the loss of N-1 replicas. Clarification and expansion of NB Broker to act as a WS container Integration with Axis 2.0 as Message Oriented Middleware infrastructure Support for High Performance transport and representation for Web Services Needs Context catalog under development Performance based routing The broker network will dynamically respond to changes in the network based on metrics gathered at individual broker nodes. Replicated publishers for fault tolerance Pure client P2P implementation (originally we linked to JXTA) Security Enhancements for fine-grain topic authorization, multi- cast keys, Broker attacks

41. 41 SOAP Message Structure II Content of individual headers and the body is defined by XML Schema associated with WS-* headers and the service WSDL SOAP Infoset captures header and body structure XML Infoset for individual headers and the body capture the details of each message part Web Service Architecture requires that we capture Infoset structure but does not require that we represent XML in angle bracket value notation H1H4H3H2 Body bp1bp2 bp3 hp1hp2hp3hp4hp5 Infoset represents semantic structure of message and its parts

42. 42 High Performance XML I There are many approaches to efficient “binary” representations of XML Infosets MTOM, XOP, Attachments, Fast Web Services DFDL is one approach to specifying a binary format Assume URI-S labels Scheme and URI-R labels realization of Scheme for a particular message i.e. URI- R defines specific layout of information in each message Assume we are interested in conversations where a stream of messages is exchanged between two services or between a client and a service i.e. two end-points Assume that we need to communicate fast between end- points that understand scheme URI-S but must support conventional representation if one end-point does not understand URI-S

43. 43 High Performance XML II First Handler Ft=F1 handles Transport protocol; it negotiates with other end-point to establish a transport conversation which uses either HTTP (default) or a different transport such as UDP with WSRM implementing reliability URI-T specifies transport choice Second Handler Fr=F2 handles representation and it negotiates a representation conversation with scheme URI-S and realization URI-R Negotiation identifies parts of SOAP header that are present in all messages in a stream and are ONLY transmitted ONCE Fr needs to negotiate with Service and other handlers illustrated by F3 and F4 below to decide what representation they will process F1F2F3 F4 Container Handlers

44. 44 High Performance XML III Filters controlled by Conversation Context convert messages between representations using permanent context (metadata) catalog to hold conversation context Different message views for each end point or even for individual handlers and service within one end point Conversation Context is fast dynamic metadata service to enable conversions NaradaBrokering will implement Fr and Ft using its support of multiple transports, fast filters and message queuing; H1H4H3H2Body Service Conversation Context URI-S, URI-R, URI-T Replicated Message Header Transported Message Handler Message View Service Message View Container Handlers FtFrF3 F4

45. 45 GIS and Sensor Grids OGC has defined a suite of data structures and services to support Geographical Information Systems and Sensors GML Geography Markup language defines specification of geo-referenced data SensorML and O&M (Observation and Measurements) define meta-data and data structure for sensors Services like Web Map Service, Web Feature Service, Sensor Collection Service define services interfaces to access GIS and sensor information Grid workflow links services that are designed to support streaming input and output messages We are building Grid (Web) service implementations of these specifications for NASA’s SERVOGrid

46. 46 Raw to GML via NaradaBrokering The Scripps Orbit and Permanent Array Center (SOPAC) GPS station network data published in RYO format is converted to ASCII and GML

47. 47 A Screen Shot From the WMS Client

48. 48 WMS uses WFS that uses data sources Northridge2 Wald D. J. -118.72,34.243 - 118.591,34.176

49. 49 Role of WS-Context There are many WS-* specifications addressing meta- data and both many approaches and many trade-offs We heard about Distributed Hash Tables (Chord) to achieve scalability in large scale networks Managed dynamic workflows as in sensor integration and collaboration require Fault-tolerance Ability to support dynamic changes with few millisecond delay But only a modest number of involved services (up to 1000’s) We are building a WS-Context compliant metadata catalog supporting distributed or central paradigms Use for OGC Web catalog service with UDDI for slowly varying meta-data

50. 50 Controlling Streaming Data NaradaBrokering capabilities can be created by messages (as in WS-*) and by a scripting interface that allows topics to be created and linked to external services Firewall traversal algorithms and network link performance data can be accessed HPSearch offers this via JavaScript This scripting engine provides a simple workflow environment that is useful for setting up Sensor Grids Should be made compatible with Web Service workflow (BPEL) and streaming workflow models Triana and Kepler Also link to WS-Management

51. 51 Collaboration Grids As with all Grids, we will use a SOA and identify what core Grid (WS) services one needs and build on top of this Core collaboration interface specification XGSP Common collaboration services such as session management and secure software multicast Customized collaboration services in particular domains Support asynchronous and synchronous collaboration Most Grids naturally support asynchronous sharing Need to see how to link to existing SIP and H323 capabilities Need to examine current monolithic collaboration architectures and divide into simple services MCU becomes multiple services

52. 52 Collaboration and Web Services Collaboration has a)Mechanism to set up members (people, devices) of a “collaborative sessions” b)Shared generic tools such as text chat, white boards, audio- video conferencing c)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 make it a WS

53. 53 Shared Event Collaboration All collaboration is about sharing events defining state changes Audio/Video conferencing shares events specifying in compressed form audio or video Shared display shares events corresponding to change in pixels of a frame buffer Instant Messengers share updates to text message streams Microsoft events for shared PowerPoint (file replicated between clients) as in Access Grid Finite State Change NOT Finite State Machine architecture Using Web services allows one to expose update events of all kinds as message streams Need publish/subscribe approach to share messages (NB) plus System to control “session” – who is collaborating and rules XGSP is XML protocol for controlling collaboration building on H323 and SIP

54. 54 Web Services and M-MVC Web Services are naturally M-MVC – Message based Model View Controller with Model is Web Service Controller is Messages (NaradaBrokering) View is rendering As Controller

55. 55 WS Display WS Viewer WS Display WS Viewer Event (Message) Service Master WS Display WS Viewer Collaboration as a WS Set up Session with XGSP Web Servic e F I U O F I R O Shared Input Port (Replicated WS) Collaboration Other Participants Web Servic e F I U O F I R O F I U O F I R O

56. 56 WS Display WS Viewer WS Display WS Viewer Event (Message) Service Master WS Display WS Viewer Web Service Message Interceptor Collaboration as a WS Set up Session with XGSP Application or Content source WSDL Web Service F I U O F I R O Shared Output Port Collaboration Other Participants Text Chat Whiteboard Multiple masters

57. 57 GlobalMMCS Web Service Architecture SIPH323 Access GridNative XGSP Admire Gateways convert to uniform XGSP Messaging High Performance (RTP) and XML/SOAP and.. Media Servers Filters Session Server XGSP-based Control NaradaBrokering All Messaging Use Multiple Media servers to scale to many codecs and many versions of audio/video mixing NB Scales as distributed Web Services NaradaBrokering

58. 58 GlobalMMCS Architecture Event Messaging Service (NaradaBrokering) XGSP Conference Control Service Audio Video Web Service Instant Messaging Web Service Shared Display Web Service Shared …. Web Service Non-WS collaboration control protocols are “gatewayed” to XGSP NaradaBrokering supports TCP (chat, control, shared display, PowerPoint etc.) and UDP (Audio-Video conferencing)

59. 59 XGSP Example: New Session GameRoom chess chess-0 John false chess-0 Bob black chess-0 Jack white

60. 60 XGSP AV Signaling Protocol with H.323

61. 61 Average Video Delays for one broker – Performance scales proportional to number of brokers Latency ms # Receivers One session Multiple sessions 30 frames/sec

62. 62 Multiple Brokers – Multiple Meetings 4 brokers can support 48 meetings with 1920 users in total with excellent quality. This number is higher than the single video meeting tests in which four brokers supported up to 1600 users. When we repeated the same test with meeting size 20, 1400 participants can be supported. Number of Meetings Total users Broker1 (ms) Broker2 (ms) Broker3 (ms) Broker4 (ms) 4016003.346.938.438.37 4819203.938.4614.6210.59 6024009.04170.0489.9725.83 Number of Meetings Total users Broker1 (%) Broker2 (%) Broker3 (%) Broker4 (%) 4016000.00 4819200.120.290.50 6024000.161.302.512.82 Latency for meeting size 40 loss rates

63. 63 PDA Download video (using 4- way video mixer service) PDA Desktop

64. 64 Linked Stream applications Note NaradaBrokering supports composite streams linking “atomic streams” Support hybrid codecs that mix TCP (lossless) and RTP (lossy) algorithms Supports time-stamped annotations of sensor streams Atomic and composite streams can be archived and replayed Video Annotated Video Frame e-Sports Project