Transcript JXTA and Web Services and Messages PTLIU Laboratory for Community Grids

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
[email protected]
5/22/2016
uri="http://www.naradabrokering.org"
email="[email protected]"
1
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
5/22/2016
uri="http://www.naradabrokering.org" email="[email protected]"
2

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
5/22/2016
uri="http://www.naradabrokering.org" email="[email protected]"
3
Peers
Database
Database
Resource Facing
Web Service Interfaces
Event/
Message
Brokers
Integrate P2P
and Grid/WS
Event/
Message
Brokers
Peer to Peer Grid
Web Service Interfaces
Peers
User Facing
Web Service Interfaces
5/22/2016
uri="http://www.naradabrokering.org" email="[email protected]"
4
A
democratic organization
Peer to Peer Grid
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
5/22/2016
uri="http://www.naradabrokering.org" email="[email protected]"
5
NaradaBrokering implements an
Event Web Service
Destination
Source Matching
Routing
Web
Service 1
WSDL
Ports




(Virtual)
Queue
Broker
Filter
workflow
Web
Service 2
WSDL
Ports
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 PublishSubscribe mechanism
5/22/2016
uri="http://www.naradabrokering.org" email="[email protected]"
6
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
5/22/2016
uri="http://www.naradabrokering.org" email="[email protected]"
7
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
5/22/2016
uri="http://www.naradabrokering.org" email="[email protected]"
8
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
5/22/2016
uri="http://www.naradabrokering.org" email="[email protected]"
9
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
5/22/2016
uri="http://www.naradabrokering.org" email="[email protected]"
10
Single Server P2P Illusion
Data
base
Traditional Collaboration Architecture
e.g. commercial WebEx
Collaboration Server
5/22/2016
uri="http://www.naradabrokering.org" email="[email protected]"
11
Narada Broker Network
(P2P) Community
For message/events service
Broker
Broker
(P2P) Community
Resource
Broker
Broker
(P2P) Community
Data
base
Broker
Software multicast
Broker
(P2P) Community
5/22/2016
uri="http://www.naradabrokering.org" email="[email protected]"
12
NaradaBrokering and JMS (Java Message Service)
Low Rate; Small Messages
5/22/2016
(commercial JMS)
uri="http://www.naradabrokering.org" email="[email protected]"
13
Narada/JXTA Event
For duplicate
detection
within
NARADA
Narada Headers
Interaction UUID
JXTA Interaction
Type
Allows the
NARADA
system to
route event to
specific JXTA
proxies
5/22/2016
Request/
Response
Peer group id
Peer id
JXTA Event
Payload
Narada Event
Distribution Traces
uri="http://www.naradabrokering.org" email="[email protected]"
Present if the
interaction is
trageted to a
specific Peer
14
NaradaBrokering and JXTA
Comparing Pure JXTA, Narada-JXTA and Direct P2P
Narada-JXTA provides JXTA guaranteed long distance delivery
9.5
Transit Delay (Milliseconds)
High end "long lived"/
persistent resources
Pure JXTA
Narada-JXTA
JXTA Direct P2P
9
8.5
8
7.5
7
Small Payload
6.5
NARADAJXTA proxy
6
5.5
NARADA
broker cloud
5
50
10
9.5
100
150
200
250
300
Message Payload Size
350
400
(Bytes)
450
500
Pure JXTA
Narada-JXTA
JXTA Direct P2P
9
8.5
8
Transit Delay
(Milliseconds)
7.5
Larger Payload
7
6.5
Peers
6
Dynamic/fluid
peer groups
5.5
5
500
JXTA
Rendezvous
PEER
1000 1500 2000 2500 3000 3500 4000 4500 5000
Message Payload Size (Bytes)
5/22/2016
uri="http://www.naradabrokering.org" email="[email protected]"
15
JXTA just got slower
100
Client  JXTA  JXTA  Client
90
80
Client  JXTA  Narada  JXTA  Client
70
60
50
Client  JXTA  JXTA  Client multicast
40
30
Narada
Client
20
Pure Narada 2 hops
Client
10
Narada
0
0
5/22/2016
100
200
300
400
Message Payload Size
(Bytes)
500
uri="http://www.naradabrokering.org" email="[email protected]"
600
16
PDA Collaboration Event Filter
GM S( Sub scr ib er )
GM SM E
10000
Message/Second
1000
100
GMS =
JMS or
Narada
10
1
5/22/2016
1M
25
6K
64
K
16
K
4K
1K
25
6
64
16
4
1
0.1
Message
Size (bytes)
uri="http://www.naradabrokering.org"
email="[email protected]"
17
Shared Input Port (Replicated WS) Collaboration
Collaboration as a WS
Set up Session
R
U
Web
F
Servic
I
I
e
O
O
F
WS
Viewer
WS
Display
Master
U
Web
F
Servic
I
I
e
O
O
F
Event
(Message)
Service
R
R
U
Web
F
Servic
I
I
e
O
O
F
5/22/2016
WS
Viewer
WS
Display
Other
Participants
WS
Viewer
uri="http://www.naradabrokering.org" email="[email protected]"
WS
Display
18
Shared Output Port Collaboration
Collaboration as a WS
Set up Session
Web Service Message
Interceptor
F
I
R
O
Master
WSDL
U
Application or
Content source
Web Service
O
F
I
Event
(Message)
Service
5/22/2016
WS
Viewer
WS
Display
WS
Viewer
WS
Display
Other
Participants
WS
Viewer
uri="http://www.naradabrokering.org" email="[email protected]"
WS
Display
19
Web Service Architecture
for Audio Video Conferencing
Access
Grid
SIP
Client
H.323
Client
A/V Web-Service
Gateway
( H.323)
A/V Media
Server
A/V Web-Service
Gateway ( SIP )
A/V Media
Server
A/V Web-Service
Gateway ( AG )
A/V Media
Server
Event Message Service
Session
Server
Session
Server
Session
Server
Core Collaboration MiddleWare
5/22/2016
uri="http://www.naradabrokering.org" email="[email protected]"
20
XGSP: Introduction
Registration
Method
Session Command
Method
Query
Method
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
5/22/2016
uri="http://www.naradabrokering.org" email="[email protected]"

21
XGSP: Example
<SessionDes>
<SessionName> PervasiveTech Seminar </SessionName>
<SessionID> 1234567 </SessionID>
<SessionCreator> [email protected] </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> [email protected] </Participant>
<Participant> [email protected] </Participant>
<Participant> [email protected] </Participant>
</SessionParticipants>
<ContactInfo> [email protected] </ContactInfo>
</SessionDes>
5/22/2016
uri="http://www.naradabrokering.org" email="[email protected]"
22
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
5/22/2016
uri="http://www.naradabrokering.org" email="[email protected]"
23