NaradaBrokering Grid Messaging and Applications as Web Services
1. NaradaBrokering Grid Messaging and Applications as Web Services Geoffrey Fox Presenter: Marlon Pierce Community Grids Lab Indiana University [email_address]
2.
3. NaradaBrokering Queues Web Service A Web Service B Stream Minicomputer Firewall Computer Server PDA Modem Laptop computer Workstation Peers Peers Audio/Video Conferencing Client Audio/Video Conferencing Client NaradaBrokering Broker Network
4.
5.
6.
7.
8. Grid Messaging Substrate Consumer Service SOAP+HTTP GridFTP RTP …. Standard client-server style communication. Substrate mediated communication removes transport protocol dependence. e.g. Now can use GridFTP with multi-stream performance boost for any message flow Messaging Substrate Consumer Service SOAP+HTTP GridFTP RTP …. Any Protocol satisfying QoS
9.
10.
11.
12.
13. Pentium-3, 1GHz, 256 MB RAM 100 Mbps LAN JRE 1.3 Linux hop-3 0 1 2 3 4 5 6 7 8 9 100 1000 Transit Delay (Milliseconds) Message Payload Size (Bytes) Mean transit delay for message samples in NaradaBrokering: Different communication hops hop-2 hop-5 hop-7
24. Yes No Yes end-to-end Security Yes Yes No Support for XPath queries/ subscriptions Yes No Yes Communication through proxies and firewalls Yes No No Support for Audio/Video Conferencing & raw RTP clients JXTA and later Gnutella Yes No Support for routing P2P Interactions Yes Yes Yes Guaranteed Messaging (Robust) No Yes Medium (MQ is based on the point-to-point model. There is a limit on the effectiveness of this mode in large configurations). WebSphere MQ (formerly MQSeries) Yes No Network Performance Monitoring Yes No JMS Compliant Very large Very large Maximum number of nodes hosting the messaging infrastructure NaradaBrokering Pastry Functionality I
25. Yes No Yes Multiple transport protocols over multiple hops. TCP (Blocking and non-blocking), UDP, Multicast, HTTP, SSL, RTP, (GridFTP) TCP, UDP TCP, HTTP, Multicast, SSL, SNA etc. Transport Protocols Supported Fair with some “production” testing Fair Extremely mature , with very robust diagnostic information Maturity of Software Platforms supporting Java 1.4 (tunneling C++) Supported on platforms which support C# (Microsoft) or Java (Rice). 35 different OS/ platforms supported. Also supports the Java Platform. Platforms or Hosting Environments No Yes (Squirrel) No Support for P2P distributed caching No Yes WebSphere MQ (formerly MQSeries) In Progress No Broker Network Design Interface No No Workflow Support NaradaBrokering Pastry Functionality II
26.
27.
28.
29.
30. SequenceTerminated Unknown Sequence InvalidAcknowledgement MessageNumberRollover LastMessageNumberExceeded InvalidMessageHeader Invalid MessageIdentifier InvalidReferenceToMessageId InvalidTimeStamp InvalidExpiryTime InvalidReliableMessage InvalidAckRequested InvalidMessageOrder Fault Codes supported by protocol Relies on WS-Security and assorted specifications Relies on WS-Security and assorted specifications Security At most once, at least once and exactly once. Order is not necessarily tied to guaranteed delivery. Exactly once ordered delivery, reliable delivery. Order is always tied to guaranteed delivery and cannot be separately specified. Delivery sequences supported WS-Policy assertions are used to meet delivery assurances. Is initiated by the sender. Quality of Service Allows the specification of a RetransmissionInterva l for a sequence (effects every message in the sequence). The interval can also be adjusted based on the exponential backoff algorithm. Triggered after receipt of a set of acknowledgements. In the event an acknowledgement is not received, the message is retransmitted until a specified number of resend attempts have been made. Retransmissions No explicit reference to UTC. Uses the dateTime format. Are expressed as UTC and conforms to a [XML Schema Part2: Data Types] dateTime element. Timestamps The identifier associated with the sequence of messages and the message number within that sequence. The identifier associated with the message being acknowledged. Correlation associated with an Acknowledgement AckRequested is used to request the receiving entity to acknowledge the message received. This is not REQUIRED. The AckRequested element is REQUIRED in every message for which reliable delivery needs to be ensured. Requesting acknowledgements Acknowledgements can be based on a range of messages, and the timing for issuing this can be advertised in a policy. An endpoint may also choose to send acknowledgements at any time. Can be sent upon receipt of messages, as a callback or in response to a poll. Needed upon receipt of every message. Acknowledgements Message number is REQUIRED for every message that needs to be delivered reliably. REQUIRED only for guaranteed ordering. Presence of numbering information and its relation to delivery No new sequences can be generated. MessageRollover fault is issued. Generate a new group identifier and begin new sequence only after receipt of last message in old sequence. Sequence numbering rollover Starts at 1 for the first message in a group. Starts at 0 for the first message in a group. Sequence numbering initialization URI based [RFC 2396]. No additional requirement. Messages within a sequence are identified based on message numbers. URI based [RFC 2396], the syntax for the message-ID should be based on what is outlined in RFC2392. Unique Ids WS-Policy, WS-Security SOAP, WS-Security Related Specifications WSRM provides an XML schema for elements needed to support the reliable messaging framework. The specification provides a SOAP binding for the protocol. Is a SOAP based protocol, which has an HTTP binding which facilitates acknowledgements and faults to be issued over HTTP responses. SOAP related issues WS-RM WS-Reliability
46. Web Service Model for Application Development Interrupts in traditional monolithic applications become “real messages” not directly method calls Natural for collaboration and universal access Natural in MVC Model W3C DOM User Interface W3C DOM Raw (UI) Events Application as a Web service W3C DOM Semantic Events Data User Facing Ports Resource Facing Ports Events as Messages Rendering as Messages View Control Model Narada Brokering
49. 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 Shared Output Port Collaboration Other Participants Text Chat Whiteboard Multiple masters WS Display WS Viewer Application or Content source WSDL Web Service F I U O F I R O
50. SIMD Collaboration Identical Programs receiving identical events Token determines if browser is moving, waiting for opponent or an observer Shared Output port SIMD Collaborative Web Service Non Web Service Implementation SVG Browser SVG Browser SVG Browser SVG Browser SVG Viewer SVG Viewer SVG Viewer SVG Viewer SVG Model (DOM) NaradaBrokering NaradaBrokering
51. Event (Message) Service Master Collaboration as a WS Set up Session with XGSP Shared Input Port ( Replicated WS) Collaboration Other Participants WS Display WS Viewer WS Display WS Viewer WS Display WS Viewer Web Service F I U O F I R O Web Service F I U O F I R O Web Service F I U O F I R O
52. MIMD Collaboration NaradaBrokering Shared Input port MIMD Collaborative Web Service SVG Viewer SVG Viewer SVG Viewer SVG Viewer SVG Model SVG Model SVG Model SVG Model NaradaBrokering
53.
54. XGSP Web Service MCU Architecture Gateways convert to uniform XGSP Messaging High Performance (RTP) and XML/SOAP and .. Use Multiple Media servers to scale to many codecs and many versions of audio/video mixing NB Scales as distributed Web Services NaradaBrokering SIP H323 Access Grid Native XGSP Admire Media Servers Filters Session Server XGSP-based Control NaradaBrokering All Messaging
55.
56.
57.
58.
59.
60.
61.
62.
63. 0 10 20 30 40 50 60 0 200 400 600 800 1000 1200 1400 1600 1800 2000 Delay (Milliseconds) Packet Number Average delays per packet for 50 video-clients NaradaBrokering Avg=2.23 ms, JMF Avg=3.08 ms NaradaBrokering-RTP JMF-RTP
64. 0 1 2 3 4 5 6 7 8 0 200 400 600 800 1000 1200 1400 1600 1800 2000 Jitter (Milliseconds) Packet Number Average jitter (std. dev) for 50 video clients. NaradaBrokering Avg=0.95 ms, JMF Avg=1.10 ms NaradaBrokering-RTP JMF-RTP
Every broker in NaradaBrokering incorporates a monitoring service (as shown in Figure 12) that monitors the state of the links originating from the broker node. Metrics computed and reported over individual links, originating from a broker node, include bandwidth , jitter , transit delays , loss rates and system throughputs . Factors are measured in a non-intrusive way so as to ensure that the measurements do not further degrade the metrics being measured in the first place. Factors such as bandwidth measurements, which can pollute other metrics being measured, are measured at lesser frequencies. Furthermore, once a link is deemed to be at the extreme ends of the performance spectrum (either very good or very bad) the measurement of certain factors are turned off while others are measured at a far lower frequency . The monitoring service then reports this data to a performance aggregator node, which aggregates information from monitoring services running at other nodes.
The integration is based on the proxy model, which essentially acts as the bridge between the NaradaBrokering system and JXTA. The Narada-JXTA proxy, operating inside the JXTA rendezvous layer, serves in a dual role as both a rendezvous peer and as a NaradaBrokering client providing a bridge between NaradaBrokering and JXTA. NaradaBrokering could be viewed as a service by JXTA. We make no changes to the JXTA core and the associated protocols. We make additions to the rendezvous layer for integration purposes. Second, this integration should entail neither any changes to the peers nor a restriction of the interactions that these peers could have had prior to the integration. Peers do not know that the broker network is routing some of their interactions. Furthermore, these Narada-JXTA proxies, since they are configured as clients within the NaradaBrokering system, inherit all the guarantees that are provided to NaradaBrokering clients.
The figure above depicts the sequence of operations involved in securing messaging within NB. When an entity requests permission to publish, the KMC responds back with a topic key if the entity is authorized to publish to the topic. The entity then proceeds to encrypt the message with the topic key, compute a message digest and sign the message digest with its personal private-key. Individual Brokers upon receipt of the secure message can verify the entity signatures and permissions. If it is not authorized to publish or if the message integrity is compromised (revealed by the message digest) the message is discarded. When an entity requests permission to subscribe to a topic, the KMC returns it the topic keys if the entity is authorized to subscribe. Since the subscription needs to be propagated within the system, the entity propagates its subscription request by signing the request with its personal public-key. Upon receipt of a secure message, the subscriber verifies the signature and integrity of the message. It then proceeds to decrypt the secure message with the KMC supplied secret topic-key.
Standarad deviation between inter packet arrival times
![NaradaBrokering Grid Messaging and Applications as Web Services Geoffrey Fox Presenter: Marlon Pierce Community Grids Lab Indiana University [email_address]](https://image.slidesharecdn.com/naradabrokering-grid-messaging-and-applications-as-web-services4930/85/naradabrokering-grid-messaging-and-applications-as-web-services-1-320.jpg)
![NaradaBrokering might Support ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)