NaradaBrokering for DS-RT 2005 Grid Tutorial

1. NaradaBrokering for DS-RT 2005 Grid Tutorial IEEE DS-RT 2005 Montreal Canada Oct. 9 2005 Geoffrey Fox CTO Anabas Corporation and Computer Science, Informatics, Physics Pervasive Technology Laboratories Indiana University Bloomington IN 47401 gcf@indiana.edu http://www.infomall.org

2. Grid (Web Service) Messaging • Build distributed systems from “interoperable” services linked by messages (SOAP) – architect capabilities as services • Grids are “just” large scale sets of such services • Need to support real time streams and NOT just files (collections of messages) consistent with WS standards (P2P and “central”) • Open Source http://www.naradabrokering.org (4 downloads/day) is a scalable distributed pub-sub system supporting multiple standards (JMS, WS) and subscription methods • Implements “Service Internet” and Notification areas of WS-* Infrastructure • Manage messaging for • Optimize communication for bad links, firewalls etc • Collaboration (multi-cast streams) • Fault tolerance with re-transmitted messages and Replicated Services • Replay – access any message at any time • Virtualize addressing with pub-sub metaphor • Performance from protocol (UDP v Parallel TCP ..) and representation • Heterogeneous Clients – filter to and from PDA’s • Candidate for Axis2-MOM (Message Oriented Middleware) infrastructure

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

4. Traditional NaradaBrokering Features

5. Features for March—June 2005 Releases • Production implementations of WS-Eventing, WS-Notification, WS-RM and WS-Reliability. • SOAP message supportand 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

6. Summary • NaradaBrokering provides a fully distributed queue manager where queues buffer streams with overheads of a few milliseconds per broker • << 30 ms frame interval • << 100’s ms network delay • Much faster than using databases or writing files • Collaboration is implemented by sharing synchronizing streams • Compatible with Grids, Web Services, Java Message Service • Streams are “first class entities” with rich set of features • Don ‘t open a socket; hand data to NaradaBrokering • Software Overlay Network or Message Oriented Middleware

7. NaradaBrokering Services

8. Reliable Delivery Service • Guaranteed delivery in multiple producer/ consumer settings. Guarantees hold true in the presence of • Node/Link Failures • Links can lose messages and garble message order. • Storage failures: Stores need to recover after failure. • Prolonged entity disconnects • Exactly-Once and Ordered delivery of events • Uses both positive& negative acknowledgements • Supports Replay and Fast Recovery from failures • Independent of underlying archival system. • Was used to enhance fault tolerance in Grid-FTP. • Uses “Reliable Storage” to keep messages temporarily

11. Dealing with large payload sizes • To cope with large payloads, the substrate incorporate 2 sets of services. • Compression/Decompression service: The substrate incorporate support for zlib based compression and decompression of payloads. • Fragmentation/Coalescing Service: These service can break up a large payload into smaller fragments. The coalescing service can take these smaller fragments and coalesce them into the original large payload. • This was used to deal with transfer of large payloads (up to 1 GB) in the NB enhanced Grid-FTP application.

12. Replay Services • Replay requestors can specify replays based on several parameters • A range of sequence numbers can be specified. • Additionally, constraints on an event’s content synopsis can be specified. • Based on a specified time range. • Replay services have been tested with applications such as Audio/Video conferencing, Whiteboards etc. • Essential for recording and replay of collaborative sessions • Important special case supports rewind and similar operations on a real-time stream

13. Buffering Service • This service is incorporated into the system to facilitate the buffering of events prior to releasing them. • Buffering service time orders events and releases event based on three metrics • Number of events in the buffer • Size of the buffer • Time spent by event in a buffer.

14. Time Differential Service • This service is essential to reduce jitters in large distributed environments. • Networks introduce unpredictable delays that increase jitter. • Service takes events released by buffering service, and ensures that it preserves time spacing between events. • TDS can provide time spacing resolution of up to 1 millisecond between events.

15. Trans-Atlantic Settings

16. Trans-Atlantic Settings

17. NaradaBrokering NTP Service • NaradaBrokering includes an implementation of the Network Time Protocol (NTP) • All entities within the system use NTP to communicate with atomic time servers maintained by organizations like NIST and USNO to compute offsets • Offset is the computed difference between global time and the local time. • The offset is computed based on the time returned from multiple atomic time servers. • The NTP algorithms weighs results from individual time clocks based on the distance of the atomic server from the entity. • This ensures that all entities are within 1 ms of each other. • The timestamps account for clock drifts on machines • Time returned corrects software clocks which can slow down with increased computing load on the machine.

19. Broker Discovery Service • Locates the nearest available broker that a client can connect to. • Incorporates specialized nodes – broker discovery nodes – to maintain broker info. • Depending on load or security issues, brokers may decide to respond/ignore discovery requests. • If available the scheme can exploit IP multicast for discovery. • Nearest broker determined by ping times, loss rates and available bandwidth.

20. Broker Discovery: Brokers at Indianapolis, NCSA, UMN, FSU, IU & San Diego Supercomputing Center. Broker at Indy selects IU, NCSA and UMN for pings.

21. Broker Discovery: Brokers at Indianapolis, NCSA, University of Minnesota, FSU & San Diego Supercomputing Center. Cardiff selects Indy, NCSA and UMN for pings.

22. Topic Discovery Service • Allows publishers and subscribers to advertise topics. • Creator of topic possesses credentials to indicate ownership of the topic. • Discovery of topics takes into account credentials of client trying to discover topic. • Topic owner may restrict discovery to a limited authorized set of clients. • Discovery requests can be made using simple strings or regular expression queries.

23. Security Service • Based on Message Level Security • Messages organized into topics • Each topic has a separate key; Topics can be organized into sessions

24. NaradaBrokering Support for SOAP and Web Services

25. SOAP Support I • The broker can receive SOAP messages (over HTTP) from any entity. • This removes any client dependence in client-broker interaction • The broker can function as an intermediary performing multiple roles which could just be routing but also involve mapping using filters • There can be multiple filter-pipelines, each comprising multiple filters, available at the broker node. • Some of these would be system filter-pipelines configured statically. • Filter-Pipelines can also be configured by users, dynamically, at run-time.

26. SOAP Support II • Multiple roles could be associated with • Different servlets hosted by a broker. • A given servlet hosted by a broker. • Scheme will allow filters to be registered for individual roles. • A filter could be part of multiple roles. • There is a dedicated filter pipeline per role. • This implies that a NaradaBroker can be used as a Web Service container although full container support is not yet available • Filters are used internally by NB to implement performance monitoring

27. The FilterPipeline-Filter model I • The filter and filter-chain facilitate many of the interactions that are missing in JAX-RPC handlers. • Filters are NaradaBrokering approach to the handlers used in Web Service containers • Filters can inject messages at any time • These messages can be sent either to the application or over the network. • No limit on the number of messages that can be triggered because of a single message from application. • Messages can be injected into a Filter Pipeline from either directions. • Filters can generate responses automatically. No need to route to application.

28. The FilterPipeline-Filter model II • Applications have access to individual filters and filter-pipeline at all times. Explicitly direct which filters need to be skipped or added. • Filters have access to position within Filter Pipeline, and can specify message injection at a specific location. • Dynamic reconfiguration possible for Filter Chain. • Allow different networking substrates to be registered. This can be dynamically changed. • Network substrate is last filter and is responsible ONLY for routing SOAP message.

29. Web Services Support I • Currently we have incorporated support for the following Web Service specifications • WS-Eventing (WSE): This is a publish/subscribe based notification framework from Microsoft and IBM. • WS-ReliableMessaging WSRM): This is a protocol for ensuring the guaranteed delivery of SOAP messages between 2 Web Service endpoints. This specification is from IBM and Microsoft. • WS-Reliability (WSR)- This is a competing specification from Oracle and Sun in the area of reliable messaging between Web Services. • These handlers are available for use in Axis1.2 or exploiting NB SOAP Intermediary support without a container • Axis1.2 version can be used inside container or as a Proxy

30. Web Services Support - II • We are also working on implementing support for the WS-Notification (WSN) suite of specification that is part of the Web Services Resource Framework (WSRF). • WS-Notification explicitly adds brokers to Eventing • Note that almost all these specifications leverage the WS-Addressing (WSA) specification. • We have incorporated support for all the rules associated with WSA.

31. NaradaBrokering in Web Services • a) WSM WSR WSN WSE support for Axis1.2 which is available as standalone handlers without need for any NaradaBrokers • b) The support described in a) implemented as a separate proxy and inside containers • c) NaradaBrokers used as SOAP Intermediaries • d) NaradaBrokers can support filters in SOAP intermediaries forming limited light-weight containers • e) NaradaBrokers can be Brokers defined in WSN Specification • f) One can use NaradaBrokers in non-brokered publish-subscribe such as WS-Eventing to make it scalable

32. Implementation of WS-Reliable Messaging (WSRM) I

33. Implementation of WS-Reliable Messaging (WSRM) II

34. Transport Layer in NaradaBrokering

35. Transport Layer • Support for multiple network protocols such as TCP, UDP, Multicast, SSL, RTP, HTTP and Parallel TCP. • Support for both blocking and non-blocking IO in the TCP support. • The UDP support manages payloads greater than 64K datagram limit. Also incorporates pinging mechanism to detect connection losses in connectionless setting. • Tunnel through firewalls/proxies • Microsoft’s ISA, Checkpoint, Apache

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

40. Performance of NaradaBrokering in collaborative settings

46. “GridMPI” v. NaradaBrokering • In parallel computing, MPI and PVM provided “all the features one needed’ for inter-node messaging • NB aims to play same role for the Grid but the requirements and constraints are very different • NB is not MPI ported to a Grid/Globus environment • Typically MPI aiming at microsecond latency but for 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 through broker) due to routing, processing (in NB) or packet loss recovery is important property • Grids need and can use software supported message functions and trade-offs between hardware and software routing different from parallel computing

47. HPSearch Management Engine • HPSearch is an engine for orchestrating distributed Web Service interactions • It uses an event system and supports both file transfers and data streams. • HPSearch flows can be scripted with JavaScript • HPSearch engine binds the flow to a particular set of services and executes the script. • HPSearch can access and set NaradaBrokering features (create topics, display performance data) • ProxyWebService: a wrapper class that adds notification and streaming support to a remote Web Service. • HPSearch is a streaming sensitive workflow engine

48. WMS GIS service and a data Layer

49. HPSearch (TRex) HPSearch (Danube) Actual Data flow HPSearch controls the Web services Final Output pulled by the WMS HPSearch Engines communicate using NB Messaging infrastructure Data can be stored and retrieved from the 3rd part repository (Context Service) WS Context (Tambora) GPS Database (Gridfarm001) NaradaBroker network: Used by HPSearch engines as well as for data transfer WMS Data Filter (Danube) Virtual Data flow WMS submits script execution request (URI of script, parameters) HPSearch hosts an AXIS service for remote deployment of scripts • Pattern Informatics • (Danube) • Accumulate Data • Run PI Code • Create Graph • Convert RAW -> GML Workflow (BPEL) Fragment GML (Danube)

50. RYO Binary Text GML SensorML and NaradaBrokering • OGC defined a set SensorML of specifications indicating how to integrate Sensors with its GIS Services • We are using Southern California SCIGN GPS data to prototype this Sensor Source Filter Filter You can access whicheverversion you want! NaradaBrokeringTopics