1 / 23

JXTA and Web Services and Messages

GGF5 Edinburgh July 23 2002. JXTA and Web Services and Messages. PTLIU Laboratory for Community Grids Geoffrey Fox, Shrideep Pallickara Computer Science, Informatics, Physics Indiana University, Bloomington IN 47404 http://www.naradabrokering.org http://grids.ucs.indiana.edu/ptliupages.

bettsm
Télécharger la présentation

JXTA and Web Services and Messages

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. GGF5 Edinburgh July 23 2002 JXTA and Web Services and Messages PTLIU Laboratory for Community Grids Geoffrey Fox, Shrideep Pallickara Computer Science, Informatics, Physics Indiana University, Bloomington IN 47404http://www.naradabrokering.org http://grids.ucs.indiana.edu/ptliupages gcf@indiana.edu uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

  2. JXTA and Grids • JXTA and Grid architectures can be implemented as Web Services interacting with (XML-based) messages • We built a “Grid Messaging System” NaradaBrokering that implements generalized publish-subscribe mechanism in a network of “brokers/routers/rendezvous peers” • Narada can replace Java Message Service – Grid-like system • Used to run our synchronous collaboration system Garnet supporting shared display, text chats, Jabber instant messenger …. • Narada is integrated with JXTA (as a proxy to rendezvous peers) and can provide reliable messaging between peer groups (and inside?) • We are building Collaboration (shared application and audio-video conferencing) as a Web Service • XGSP (XML General Session Protocol) is meant to include H323 SIP and (later) JXTA sessions (peer groups) • JXTA will be able to invoke Access Grid, Polycom, Shared Display sessions uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

  3. Different Web Service Organizations • Everything is a resource implemented as a Web Service, whether it be: • back end supercomputers and a petabyte data • Microsoft PowerPoint and this file • Web Services communicate by 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 • Narada is an example of Event or Message Service linking web services together uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

  4. Database Database Event/MessageBrokers Event/MessageBrokers Integrate P2P and Grid/WS Peer to Peer Grid Peers Resource FacingWeb Service Interfaces Web Service Interfaces Peers User FacingWeb Service Interfaces A democratic organization Peer to Peer Grid uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

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

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

  7. Engineering Issues Addressedby Event / Messaging Service • Application level Quality of Service – give audio highest priority • Tunnel through firewalls • Filter messages to slow (collaborative or real time) clients • Hardware multicast is erratically implemented (Event service can dynamically use software multicast) • Scaling of software multicast • Elegant implementation of Collaboration in a Groove Networks (done better) style • Integrate synchronous and asynchronous collaboration uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

  8. Features of Event Service I • MPI nowadays aims at a microsecond latency • The Event Web Service aims at a millisecond latency • Typical distributed system travel times are many milliseconds (to seconds for Geosynchronous satellites) • Different performance/functionality trade-off • Messages are not sent directly from P to S but rather from P to Broker B and from Broker B to subscriber S • Actually a network of brokers • Synchronous systems: B acts as a real-time router/filterer • Messages can be archived and software multicast • Asynchronous systems: B acts as an XML database and workflow engine • Subscription is in each case, roughly equivalent to a database query uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

  9. Features of Event Web Service II • In principle Message brokering can be virtual and compiled away in the same way that WSDL ports can be bound in real time to optimal transport mechanism • All Web Services are specified in XML but can be implemented quite differently • Audio Video Conferencing sessions could be negotiated using SOAP (raw XML) messages and agree to use certain video codecs transmitted by UDP/RTP • There is a collection of XML Schema – call it GXOS – specifying event service and requirements of message streams and their endpoints • One can sometimes compile message streams specified in GXOS to MPI or to local method call • Event Service must support dynamic heterogeneous protocols uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

  10. Features of Event Web Service III • The event web service is naturally implemented as a dynamic distributed network • Required for fault tolerance and performance • A new classroom joins my online lecture • A broker is created to handle students – multicast locally my messages to classroom; handle with high performance local messages between students • Company X sets up a firewall • The event service sets up brokers either side of firewall to optimize transport through the firewall • Note all message based applications use same message service • Web services imply ALL applications are (possibly virtual) message based uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

  11. Data base Single Server P2P Illusion Traditional Collaboration Architecturee.g. commercial WebEx Collaboration Server uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

  12. Data base Narada Broker Network (P2P) Community For message/events service Broker Broker (P2P) Community Resource Broker Broker Broker (P2P) Community Software multicast Broker (P2P) Community uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

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

  14. Narada/JXTA Event uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

  15. Small Payload Larger Payload NaradaBrokering and JXTA Comparing Pure JXTA, Narada-JXTA and Direct P2P Narada-JXTA provides JXTA guaranteed long distance delivery uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

  16. JXTA just got slower Client  JXTA  JXTA  Client Client  JXTA  Narada  JXTA  Client Client  JXTA  JXTA  Client multicast Narada Client Pure Narada 2 hops Client Narada uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

  17. PDA Collaboration Event Filter GMS =JMS orNarada uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

  18. 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 Master Event(Message)Service OtherParticipants uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

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

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

  21. XGSP: Introduction • 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 bind the RTP channels of a client into the media server uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

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

  23. NaradaBrokering Futures • Higher Performance – reduce minimum transit time to around one millisecond • Substantial operational testing • Security – allow Grid (Kerberos/PKI) security mechanisms • Support of more protocols with dynamic switching as in JXTA – SOAP, RMI, RTP/UDP • Have prototype RTP/UDP support • Integration of simple XML database model using JXTA Search to manage distributed archives • More formal specification of “native mode” and dynamic instantiation of brokers • General Collaborative Web services uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

More Related