JXTA and Web Services and Messages GGF5 Edinburgh July 23 2002 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 gcf@indiana.edu 12/31/2018 uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

uri="http://www.naradabrokering.org" email="gcf@indiana.edu" 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 12/31/2018 uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

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 12/31/2018 uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

Peer to Peer Grid Peers Integrate P2P and Grid/WS Peers Database Database Peers Resource Facing Web Service Interfaces Event/ Message Brokers Integrate P2P and Grid/WS Peer to Peer Grid Web Service Interfaces Peers User Facing Web Service Interfaces A democratic organization Peer to Peer Grid 12/31/2018 uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

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 12/31/2018 uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

NaradaBrokering implements an Event Web Service (Virtual) Queue Web Service 2 Destination Source Matching Filter Routing workflow WSDL Ports Broker 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 12/31/2018 uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

Engineering Issues Addressed by 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 12/31/2018 uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

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 12/31/2018 uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

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 12/31/2018 uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

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 12/31/2018 uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

Single Server P2P Illusion Traditional Collaboration Architecture e.g. commercial WebEx Data base Collaboration Server 12/31/2018 uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

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

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

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

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

uri="http://www.naradabrokering.org" email="gcf@indiana.edu" 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 12/31/2018 uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

PDA Collaboration Event Filter GMS = JMS or Narada 12/31/2018 uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

Event (Message) Service Shared Input Port (Replicated WS) Collaboration Collaboration as a WS Set up Session Web Service F I U O R WS Display WS Viewer Master Web Service F I U O R WS Display WS Viewer Event (Message) Service Other Participants Web Service F I U O R WS Display WS Viewer 12/31/2018 uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

Event (Message) Service Shared Output Port Collaboration Collaboration as a WS Set up Session Web Service Message Interceptor Master Application or Content source WSDL Web Service F I U O R WS Display WS Viewer WS Viewer WS Display Event (Message) Service Other Participants WS Viewer WS Display 12/31/2018 uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

Web Service Architecture for Audio Video Conferencing 12/31/2018 uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

uri="http://www.naradabrokering.org" email="gcf@indiana.edu" XGSP: Introduction Registration Method Session Command Query Session Channel Binding Method 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 12/31/2018 uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

uri="http://www.naradabrokering.org" email="gcf@indiana.edu" 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> 12/31/2018 uri="http://www.naradabrokering.org" email="gcf@indiana.edu"

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 12/31/2018 uri="http://www.naradabrokering.org" email="gcf@indiana.edu"