1. JXTA and Web Services and Messages
GGF5 Edinburgh July
PTLIU Laboratory for Community Grids
Geoffrey Fox, Shrideep Pallickara
Computer Science, Informatics, Physics
Indiana University, Bloomington IN
12/31/2018
uri="

2. 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="

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
12/31/2018
uri="

4. 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="

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
12/31/2018
uri="

6. 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="

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

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
12/31/2018
uri="

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
12/31/2018
uri="

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
12/31/2018
uri="

11. Single Server P2P Illusion
Traditional Collaboration Architecture e.g. commercial WebEx
Data
base
Collaboration Server
12/31/2018
uri="

12. 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="

13. NaradaBrokering and JMS (Java Message Service)
Low Rate; Small Messages
(commercial JMS)
12/31/2018
uri="

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

15. 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="

16. 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="

17. PDA Collaboration Event Filter
GMS = JMS or Narada
12/31/2018
uri="

18. 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="

19. 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="

20. Web Service Architecture for Audio Video Conferencing
12/31/2018
uri="

21. 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="

22. uri="http://www.naradabrokering.org" email="gcf@indiana.edu"
XGSP: Example
<SessionDes>
<SessionName> PervasiveTech Seminar </SessionName>
<SessionID> </SessionID>
<SessionCreator> </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> </SessionURI>
<SessionParticipants>
<Participant> </Participant>
<Participant> </Participant>
<Participant> </Participant>
</SessionParticipants>
<ContactInfo> </ContactInfo>
</SessionDes>
12/31/2018
uri="

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
12/31/2018
uri="