naradabrokering grid messaging and applications as web services
TRANSCRIPT
NaradaBrokeringGrid Messaging and
Applications as Web ServicesGeoffrey Fox
Presenter: Marlon PierceCommunity Grids Lab
Indiana [email protected]
NaradaBrokering might Support• Grid Messaging reliably in spirit of WS-
ReliableMessaging• Virtualize inter-service communication• Federate different Grids Together• Scalable pervasive audio-video conferencing• General collaborative Applications and Web services• Build next generation clients interacting with messages
not method-based user interrupts• Unify peer-to-peer networks and Grids• Handle streams as in “media or sensor Grids”• Handle events as in WS-Notification
Minicomputer
Firewall
ComputerServer
PDA
Modem
Laptop computerWorkstationPeers
Peers
Audio/VideoConferencing Client
Audio/VideoConferencing Client
NaradaBrokering BrokerNetwork
NaradaBrokering
Queues
Web Service A
Web Service B
Stream
“GridMPI” v. NaradaBrokering In parallel computing, MPI and PVM provided “all the features
one needed’ for inter-node messaging NB aims to play same role for the Grid but the requirements and
constraints are very different• NB is not MPI ported to a Grid/Globus environment
Typically MPI aiming at microsecond latency but for Grid, time scales are different• 100 millisecond quite normal network latency• 30 millisecond typical packet time sensitivity (this is one audio or video
frame) but even here can buffer 10-100 frames on client (conferencing to streaming)
• 1 millisecond is time for a Java server to “think” Jitter in latency (transit time through broker) due to routing,
processing (in NB) or packet loss recovery is important property Grids need and can use software supported message functions and
trade-offs between hardware and software routing different from parallel computing
NaradaBrokering Based on a network of cooperating broker nodes
• Cluster based architecture allows system to scale in size Originally designed to provide uniform software
multicast to support real-time collaboration linked to publish-subscribe for asynchronous systems.
Now has several core functions • Reliable order-preserving “Optimized” Message transport
(based on performance measurement) in heterogeneous multi-link fashion with TCP, UDP, SSL, HTTP, and will add GridFTP
• General publish-subscribe including JMS & JXTA and support for RTP-based audio/video conferencing
• Distributed XML event selection using XPATH metaphor• QoS, Security profiles for sent and received messages• Interface with reliable storage for persistent events
Laudable Features of NaradaBrokering
Is open source http://www.naradabrokering.org Has client “plug-in” as well as standalone brokers Will have a discovery service to find nearest brokers Does tunnel through most firewalls without requiring
ports to be opened Supports uniform time across a distributed network Supports JXTA, JMS (Java Message Service) and more
powerful native mode Transit time < 1 millisecond per broker Will have setup and broker network administration
module
NaradaBrokering Naturally Supports Filtering of events to support different client
requirements (e.g,. PDA versus desktop, slow lines, different A/V codecs)
Virtualization of addressing, routing, interfaces Federation and Mediation of multiple instances of Grid
services as illustrated by • Composition of Gridlets into full Grids (Gridlets are single
computers in P2P case)• JXTA with peer-group forming a Gridlet
Monitoring of messages for Service management and general autonomic functions
Fault tolerant data transport Virtual Private Grid with fine-grain Security model
Grid Messaging Substrate
Consumer Service
SOAP+HTTPGridFTPRTP ….
Standard client-serverstyle communication.
Substrate mediatedcommunication removestransport protocol dependence.
Messaging Substrate
Consumer ServiceSOAP+HTTPGridFTPRTP ….
Any Protocol satisfying QoS
e.g. Now can use GridFTP with multi-stream performance boost for any message flow
Virtualizing Communication Communication specified in terms of user goal and Quality of
Service – not in choice of port number and protocol Protocols have become overloaded e.g. MUST use UDP for A/V
latency requirements but CAN’t use UDP as firewall will not support ………
A given communication can involve multiple transport protocols and multiple destinations – the latter possibly determined dynamically
Dial-upFilter
SatelliteUDP
FirewallHTTP
A
B1
Hand-HeldProtocol
FastLink
Software MulticastB2
B3NB Broker Client Filtering
NB Brokers
Performance Monitoring Every broker incorporates a Monitoring service that
monitors links originating from the node. Every link measures and exposes a set of metrics
• Average delays, jitters, loss rates, throughput. Individual links can disable measurements for
individual or the entire set of metrics. Measurement
intervals can also be varied
Monitoring Service, returns measured metrics to Performance Aggregator.
BrokerNode
LinkData
BrokerNode
LinkData
Performance AggregationService
Control MessageExchange
Aggregates infofrom nodes in acertain domain
MonitoringService
Architecture of Message Layer Need to optimize not only routing of particular messages but classic
publish/subscribe problem of integrating different requests with related topics (subscribe to sports/basketball/lakers and sports)
Related to Akamai, AOL … caching and Server optimization problem
1-> N Grid Clients
Hypercube ofNB Brokers (logicalnot physical)
N≈100 forDistanceEducationPer edge BrokerScale with distributedBroker net?
NaradaBrokering Communication Applications interface to NaradaBrokering through UserChannels
which NB constructs as a set of links between NB Brokers acting as “waystations” which may need to be dynamically instantiated
UserChannels have publish/subscribe semantics with XML topics Links implement a single conventional “data” protocol.
• Interface to add new transport protocols within the Framework
• Administrative channel negotiates the best available communication protocol for each link
Different links can have different underlying transport implementations• Implementations in the current release include support for
TCP,UDP, Multicast, SSL, RTP and HTTP. • GridFTP most interesting new protocol• Supports communication through proxies and firewalls such as
iPlanet, Netscape, Apache, Microsoft ISA and Checkpoint.
Pentium-3, 1GHz, 256 MB RAM100 Mbps LAN
JRE 1.3 Linux
hop-3
0
1
2
3
4
5
6
7
8
9
100 1000
Tra
nsit
Del
ay
(Mill
isec
onds
)
Message Payload Size (Bytes)
Mean transit delay for message samples in NaradaBrokering: Different communication hops
hop-2
hop-5 hop-7
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
1000 1500 2000 2500 3000 3500 4000 4500 5000
Sta
nd
ard
De
via
tion
(M
illis
eco
nd
s)
Message Payload Size (Bytes)
Standard Deviation for message samples in NaradaBrokering Different communication hops - Internal Machines
hop-2hop-3hop-5hop-7
NaradaBrokering and JMS (Java Message Service)
Low Rate; Small Messages (commercial JMS)
NaradaBrokering and JXTA Federation
Based on hybrid proxy that acts as both Rendezvous peer (JXTA routers) and NaradaBrokering end-point.
No changes to JXTA core or constraints on interactions• Change made to Rendezvous
layer Peers are not aware that
they interact with a Narada-JXTA proxy or Rendezvous peer.
NARADA-JXTA proxy
NARADAbroker cloud
Peers
JXTARendezvousPEER
Dynamic/fluidpeer groups
High end "long lived"/persistent resources
NB provides JXTA guaranteed long distance delivery NB federates multiple JXTA Peer Groups
End-point Services inNative NaradaBrokering
Allows you to create Consumers (subscribers) of events (an event is a time stamped message where time stamp can be empty!)
Allows you to create Producers of events (publishers) Allows you to discover brokers and initialize
communications with the broker. Services available at the client side will perform
• Compression of payloads• Computation of Message digests for Integrity• Secure encryption of payload based on the specified keys• Fragmentation of large payloads into smaller packets• Redundancy service which maintains active (alternate)
connections to multiple brokers.
Event Consumer Capabilities Allow you to subscribe to events that conform to a certain
template.• The specified subscription profile could topic-based strings, XPath
queries, <tag=value> pairs or integer topics.
Event Consumers can also create Consumer constraints to specify various properties regarding the delivery of events.
Consumer constraints are different from subscriptions. • Subscriptions (or Profiles) are evaluated in a distributed fashion by the
broker network,
• Consumer constraints are QoS related and are managed by the QoS services running on the end-point.
Consumer constraints can specify• Reliable Delivery of events
• Ordered (Publisher, causal and time ordered) delivery of events
• Exactly once delivery of events
• Delivery after un-compression of compressed payload
• Delivery after decrypting encrypted payload
Event Producer Capabilities Facilitate the generation of events in correct format
(next slide) Facilitate the publishing of events to brokers Allow the creation of Publisher constraints which
facilitate specification of properties that need to be satisfied by published events
Among the constraints that can be specified include• Method of Securing message payloads
• Computing message digests
• Compressing message payloads
• Fragmenting large payloads
Native NaradaBrokering Event The event comprises of
• Event headers• Content Synopsis (for selection as in JMS properties
WITHOUT reading body)• Content Payload• Dissemination Traces (generated on the fly as event traverses
broker network) This is different from structure of JMS or JXTA events This NBEvent structure supports the extra capabilities discussed
earlier The event headers specify information regarding
• Security and Integrity of encapsulated payload• Fragmentation of events• Compression of payloads• Correlation identifiers (to define ordering between different
streams as is needed in some collaboration applications)• Priority• Application Type• Event Identifiers
Based on Message Level SecurityMessages organized into topicsEach topic has a separate key; Topics can be organized into sessions
Functionality I WebSphere MQ
(formerly MQSeries)Pastry NaradaBrokering
Maximum number of nodes hosting the messaging infrastructure
Medium (MQ is based on the point-to-point model. There is a limit on the effectiveness of this mode in large configurations).
Very large Very large
JMS Compliant Yes No Yes
Guaranteed Messaging (Robust)
Yes Yes Yes
Support for routing P2P Interactions
No Yes JXTA and later Gnutella
Support for Audio/Video Conferencing & raw RTP clients
No No Yes
Communication through proxies and firewalls
Yes No Yes
Support for XPath queries/ subscriptions
No Yes Yes
end-to-end Security Yes No Yes
Network Performance Monitoring
No No Yes
Functionality II WebSphere MQ
(formerly MQSeries)Pastry NaradaBrokering
Workflow Support Yes No NoSupport for P2P distributed caching
No Yes (Squirrel) No
Platforms or Hosting Environments
35 different OS/ platforms supported. Also supports the Java Platform.
Supported on platforms which support C# (Microsoft) or Java (Rice).
Platforms supporting Java 1.4 (tunneling C++)
Maturity of Software
Extremely mature, with very robust diagnostic information
Fair Fair with some “production” testing
Transport Protocols Supported
TCP, HTTP, Multicast, SSL, SNA etc.
TCP, UDP TCP (Blocking and non-blocking), UDP, Multicast, HTTP, SSL, RTP, (GridFTP)
Multiple transport protocols over multiple hops.
Yes No Yes
Broker Network Design Interface
No No In Progress
Autonomic Services In a Web (Grid) Service architecture, the state of any service is defined
by its initial condition and all the messages (including ordering) that it receives• This how shared event model of collaboration works
This is a “Finite State Change” model analogous to saving file and “undo” command in many editors
NB plus a robust store can “guarantee” to save all these messages for (all) services
This allows one to build both "autonomic data transport" and "autonomic services" since these services can sustain packet losses in transport and can also sustain failures of apps/brokers• archived messages (previous invocations, published events etc) can
be retransmitted to reconstruct state at the service or to correct a transport error.
Further anomalies in message traffic (such as a publisher or subscriber are silent) can be detected by NB and signal problems
We are building examples of both scenarios using GridFTP as our data transport example
We will build a sample autonomic visualization service with detection of failed servers and brokers
Reliable Messaging Standards
• There are 2 competing standards in the Web Services community– WS-Reliability from OASIS– WS-ReliableMessaging from IBM and
Microsoft (now expanded to include others)
WS-Reliability & WS-RM • Specifications provide reliable delivery
between two endpoints.• Both the specifications use positive
acknowledgements to ensure reliable delivery
• Both specifications include support for faults
• WS-Reliability is a SOAP based protocol• WS-ReliableMessaging provides an XML
schema for reliable messaging. – Includes a SOAP binding.
NaradaBrokering & Reliable Delivery specifications
• We can provide support for both these specifications – In NaradaBrokering we provide reliable delivery
from multiple points to multiple points
• We have identified issues that will allow federation between these specifications– Sequence numbering, fault mappings,
numbering rollovers, quality of service guarantees
• Federation would allow– WSRM sender & WS-Reliability receiver– WS-Reliability sender & WSRM receiver
WS-ReliabilityWS-RM
SOAP related issues Is a SOAP based protocol, which has an HTTP binding which facilitates acknowledgements and faults to be issued over HTTP responses.
WSRM provides an XML schema for elements needed to support the reliable messaging framework. The specification provides a SOAP binding for the protocol.
Related Specifications SOAP, WS-Security WS-Policy, WS-Security
Unique Ids URI based [RFC 2396], the syntax for the message-ID should be based on what is outlined in RFC2392.
URI based [RFC 2396]. No additional requirement. Messages within a sequence are identified based on message numbers.
Sequence numbering initialization
Starts at 0 for the first message in a group. Starts at 1 for the first message in a group.
Sequence numbering rollover Generate a new group identifier and begin new sequence only after receipt of last message in old sequence.
No new sequences can be generated.MessageRollover fault is issued.
Presence of numbering information and its relation to delivery
REQUIRED only for guaranteed ordering. Message number is REQUIRED for every message that needs to be delivered reliably.
Acknowledgements Can be sent upon receipt of messages, as a callback or in response to a poll. Needed upon receipt of every message.
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.
Requesting acknowledgements
The AckRequested element is REQUIRED in every message for which reliable delivery needs to be ensured.
AckRequested is used to request the receiving entity to acknowledge the message received. This is not REQUIRED.
Correlation associated with an Acknowledgement
The identifier associated with the message being acknowledged. The identifier associated with the sequence of messages and the message number within that sequence.
Timestamps Are expressed as UTC and conforms to a [XML Schema Part2: Data Types] dateTime element.
No explicit reference to UTC. Uses the dateTime format.
Retransmissions 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.
Allows the specification of a RetransmissionInterval for a sequence (effects every message in the sequence). The interval can also be adjusted based on the exponential backoff algorithm.
Quality of Service Is initiated by the sender. WS-Policy assertions are used to meet delivery assurances.
Delivery sequences supported Exactly once ordered delivery, reliable delivery.Order is always tied to guaranteed delivery and cannot be separately specified.
At most once, at least once and exactly once. Order is not necessarily tied to guaranteed delivery.
Security Relies on WS-Security and assorted specifications Relies on WS-Security and assorted specifications
Fault Codes supported by protocol
InvalidMessageHeaderInvalid MessageIdentifierInvalidReferenceToMessageIdInvalidTimeStampInvalidExpiryTimeInvalidReliableMessageInvalidAckRequestedInvalidMessageOrder
SequenceTerminatedUnknown SequenceInvalidAcknowledgementMessageNumberRolloverLastMessageNumberExceeded
NaradaBrokering, WS-Notification & JMS• NaradaBrokering is JMS compliant• Topics in NaradaBrokering could be based on XML,
String(as in JMS), Plain text, Integers, and (tag=value) tuples.– Subscriptions could be XPath queries, SQL queries, Regular
expressions, Strings and integers
• Almost all the primitives needed in WS-Notification are available in NaradaBrokering– Exception: Entities never communicate directly with each
other, as proposed in WS-Notification.– We are either allow such direct communication or mimic in
NB – no performance overhead!
• We are currently building a prototype implementation of WS-Notification
• Need to relate WS-Notification with WS-Eventing and WS-Events
NaradaBrokering and NTP• NaradaBrokering includes an implementation of the
Network Time Protocol (NTP)• All entities within the system use NTP to
communicate with atomic time servers maintained by organizations like NIST and USNO to compute offsets– Offset is the computed difference between global time and
the local time.– The offset is computed based on the time returned from
multiple atomic time servers.• The NTP algorithms weighs results from individual time clocks
based on the distance of the atomic server from the entity.
• NTP ensures that all entities are within 1-30 milliseconds of each other.
• The timestamps account for clock drifts that take place on machines– Time returned is based on software clocks which can slow
down with increased computing load on the machine.
NB Time Service
• In figure on left, there is a NTP daemon running on the local machine besides the NB Time Service. NTP daemon running on the machine adjusts the underlying system clock. NB Time Service shows consistent results with NTP daemon.
• Figure on right shows results on machine that does not run NTP daemon.
offset variations versus elapsed time
-4
-3
-2
-1
0
1
2
3
1.07E+12
1.07E+12
1.07E+12
1.07E+12
1.07E+12
1.07E+12
local computer time - msecs
offs
et c
hang
e -
mse
cs
offset variations versus elapsed time
-4
-3
-2
-1
0
1
2
3
1.072E+12
1.072E+12
1.072E+12
1.073E+12
1.073E+12
1.073E+12
local computer time - msecsof
fset
cha
nge
- m
secs
• The following results are obtained over a period of 48 hours. • In these tests, NB Time Service computes offset every 30 seconds.
– Usually NTP daemons on Linux/Solaris adjust underlying clock every second.
Building PSE’s with theBuilding PSE’s with theRule of the Millisecond IRule of the Millisecond I
Typical Web Services are used in situations with interaction delays Typical Web Services are used in situations with interaction delays (network transit) of 100’s of milliseconds(network transit) of 100’s of milliseconds
But basic But basic message-based interactionmessage-based interaction architecture only incurs architecture only incurs fraction of a millisecond delayfraction of a millisecond delay
Thus use Web Services to build ALL PSE componentsThus use Web Services to build ALL PSE components• Use messages Use messages and and NOT method/subroutine call or RPCNOT method/subroutine call or RPC
This “rule” OFTEN violated – people use “Java Interfaces” and so This “rule” OFTEN violated – people use “Java Interfaces” and so cannot distribute servicescannot distribute services
Interaction
Nugget1 Nugget2
Nugget3 Nugget4Data
Building PSE’s with theBuilding PSE’s with theRule of the Millisecond IIRule of the Millisecond II
Messaging has several advantages over scripting languagesMessaging has several advantages over scripting languages• Collaboration trivial by sharing messagesCollaboration trivial by sharing messages• Software Engineering due to greater modularitySoftware Engineering due to greater modularity• Web Services do/will have wonderful supportWeb Services do/will have wonderful support
““Loose” Application couplingLoose” Application coupling uses workflow technologies uses workflow technologies Find characteristic interaction timeFind characteristic interaction time (millisecond programs; (millisecond programs;
microseconds MPI and particle) and use microseconds MPI and particle) and use best supported best supported architecture at this levelarchitecture at this level• Two levels: Web Service (Grid) Two levels: Web Service (Grid) and and
C/C++/C#/Fortran/Java/PythonC/C++/C#/Fortran/Java/Python Major difficultyMajor difficulty in frameworks is NOT building them but rather in in frameworks is NOT building them but rather in
supporting themsupporting them• IMHO only hope is to always IMHO only hope is to always minimize life-cycle support risksminimize life-cycle support risks• Science is too small a field to support much!Science is too small a field to support much!
Expect to use DIFFERENT technologies at each level Expect to use DIFFERENT technologies at each level even though even though possible to do everything with one technologypossible to do everything with one technology• Trade off support versus performance/customizationTrade off support versus performance/customization
Streams and Workflow Grids need to consider streams and Services
• Topics in NB are streams not just individual messages There is service-oriented workflow where streams are
typically implicit. For stream-oriented workflow, the streams are explicit.
We have built a sophisticated system GlobalMMCS for audio-video conferencing, which we will discuss next• Media Industry and sensor based science are different
examples We are building a stream control engine for
NaradaBrokering when streams are “just” message flows on the Grid. Here one would use NB discovery services – find streams – and monitor
NB could be used as part of workflow runtime
UNIX-style Workflow Example `flow: x &> (y1|z1 &> p,(q|storage1)), (y2|z2|storage2)`;
Note this approach allows for example all workflow streams to use RMI, GridFTP, RTP – your or rather NaradaBrokering’s choice
x
y1 z1 p
y2 z2 storage2
q storage1
NaradaBrokering Topic (Queue)
Stream–oriented Workflow As in audio-video conferencing and multimedia file
delivery where it’s the media streams that are the “point”
Services generate and transform streams but one thinks of streams going through services rather than services generating streams
Multi-cast streams where video from one client sent to all other participants in a collaborative session common
One thinks of a stream being published and participants subscribing to it.
Pub/Sub QueuePublish
Subscribe
InterGrids Federated Grid using NB Build a P2P Network where each component (cell or Gridlet) is
itself a Grid If cell is a single computer, reduces to using NB to build
communication infrastructure between nodes of P2P network If cell is a JXTA peer group, then InterGrids includes previous
federation of JXTA Peer Groups
Gridlets
NB Brokers
Grid formed fromMultiple cells
InterGrids Mediation Architecture NB acts as a Mediation agent in such a Cellular Grid Using federated security model constructs a VPN like Virtual
Private Grid (NB could support VPN protocol and combine with Grid Security)
Mediation includes more than routing (as in current JXTA) as can map between Interface standards
Each Gridlet can use different Service standards Services register interfaces with mediator giving ways to map
using perhaps OGSA as a common intermediate form Allows integration of OGSI WSRF WS-GAF and “pure web
service” or Jini or JXTA based Grids where each Grid uses its natural service architecture
Support interoperable (like Job Submission) and federated (like registry or metadata catalog) services
Exploits stream filtering capability of NB
Collaboration and Web Services Collaboration has
a) Mechanism to set up members (people, devices) of a “collaborative sessions”
b) Shared generic tools such as text chat, white boards, audio-video conferencing
c) Shared applications such as Web Pages, PowerPoint, Visualization, maps, (medical) instruments ….
b) and c) are “just shared objects” where objects could be Web Services but rarely are at moment
• We can port objects to Web Services and build a general approach for making Web services collaborative
a) is a “Service” which is set up in many different ways (H323 SIP JXTA are standards supported by multiple implementations) – we should make it a WS
Shared Event Collaboration All collaboration is about sharing events defining state changes
• Audio/Video conferencing shares events specifying in compressed form audio or video
• Shared display shares events corresponding to change in pixels of a frame buffer
• Instant Messengers share updates to text message streams
• Microsoft events for shared PowerPoint (file replicated between clients) as in Access Grid
Finite State Change NOT Finite State Machine architecture Using Web services allows one to expose updates of all kinds as
messages• “Event service” for collaboration is similar to Grid notification service and we
effectively define SDE’s (service data elements) in OGSI
Group (Session) communication service is needed for the delivery of the update events• Using Event Messaging middleware makes messaging universal
Collaborative SVG Web Service SVG is W3C 2D Vector Graphics standard and is interesting for
visualization and as a simple PowerPoint like application• Further SVG is built on W3C DOM and one can generalize results
to all W3C DOM-based applications (“all” in future?) Apache Batik SVG is Java and open source and so it is practical
to modify it to explore• Real Applications as a Web Service
• Collaboration as a Web Service
• MVC model and web services with implications for portlets We use NaradaBrokering and XGSP to control collaboration;
support PDA Cell-phone and desktop clients; are restructuring Batik as MVC Web Service• Good progress in all areas see
• http://www.svgarena.org for SVG Games
• http://grids.ucs.indiana.edu/ptliupages/projects/carousel/ for PDA
Applications as Web Services? Build “all” classic applications in Web service style with user
interface and “real application” interacting by (WSDL/SOAP) messages and NOT by O/S controlled interrupts• This is “just” MVC (Model View Control) paradigm done very explicitly
• Quite hard because MVC not actually used very systematically
Perhaps the advantages of this architecture could be enough to shake the Microsoft hegemony in both O/S and “productivity” applications• Current challenges of Microsoft applications are trying to do as well and
not easy to see how they can do better
Immediately make a lot easier to support cross O/S applications Form the “Next Generation Client Consortium”?
• There is quite a lot of open source (but not web service based) software with which to begin
Classic MVC ParadigmClassic MVC Paradigm
Model View Controller
Model
Controller
ViewMouse eventKeyboard events
Figure MVC Model
Display
Web Service Model for Application Development
W3C DOM User Interface
W3C DOM Raw (UI) Events
Application as a Web serviceW3C DOM Semantic Events
Data
User FacingPorts
Resource Facing Ports
Events as Messages
Rendering as Messages
View
Control
ModelNarada
Brokering
Interrupts in traditional monolithic applications become“real messages” not directly method callsNatural for collaboration and universal access
Natural inMVC Model
Application as a Web serviceApplication as a Web service
Participating Client
RenderingRendering
User Interface
W3C DOM Events
From Master
FromCollaborationAs a WS
Events
Application as a Web serviceApplication as a Web service
Master Client
RenderingRendering
User Interface
W3C DOM Events
To Collaborative Clients
FromCollaborationAs a WS
Events
Control flow for collaborative SVG clients
Figure 3 Control flow for collaborative SVG clients
Collaborative SVG As A Web ServiceCollaborative SVG As A Web Service
NaradaBrokering
Collaborative SVG Chess Collaborative SVG Chess Game in Batik BrowserGame in Batik Browser
Players
Observers
WSDisplay
WSViewer
WS Display
WS Viewer
Event(Message)
Service
Master
WSDisplay
WS Viewer
Web Service MessageInterceptor
Collaboration as a WSSet up Session with XGSP
Application orContent source
WSDL
Web Service
F
I
U
O
F
I
R
O
Shared Output Port Collaboration
OtherParticipants
Text ChatWhiteboardMultiplemasters
SVGBrowser
SVGBrowser
SVGBrowser
SVGBrowser
Identical Programs receiving identical eventsToken determines if browser is moving, waiting for opponent or an observer
SIMD Collaboration
SVGViewer
SVGViewer
SVGViewer
SVGViewer
SVG Model (DOM)
NaradaBrokering
Shared Output portSIMD CollaborativeWeb Service
Non Web ServiceImplementation
NaradaBrokering
WSDisplay
WSViewer
WS Display
WS ViewerEvent
(Message)Service
Master
WSDisplay
WS Viewer
Collaboration as a WSSet up Session with XGSP
WebServic
e
F
I
U
O
F
I
R
O
Shared Input Port (Replicated WS) Collaboration
OtherParticipants
WebServic
e
F
I
U
O
F
I
R
O
WebServic
e
F
I
U
O
F
I
R
O
MIMD Collaboration
SVGViewer
SVGViewer
SVGViewer
SVGViewer
NaradaBrokering
Shared Input portMIMD CollaborativeWeb Service
SVG Model
SVG Model
SVG Model
SVG Model
NaradaBrokering
Global-MMCS 2.0 XGSP MCU We are building an open source protocol independent Web
Service “MCU” which will scale to an arbitrary number of users and provide integrated thousands of simultaneous users collaboration services.
We will deploy it globally and hope to test with later this year. The function of A/V media server will be distributed using
NaradaBrokering architecture.• Media Servers mix and convert A/V streams
Open XGSP MCU based on the following open source projects• openh323 is basis of H323 Gateway
• NIST SIP stack is basis of SIP Gateway
• NaradaBrokering is open source messaging from Indiana
• Java Media Framework basis of Media Servers
XGSP Web Service MCU Architecture
SIP H323 Access Grid Native XGSPAdmire
Gateways convert to uniform XGSP Messaging
High Performance (RTP)and XML/SOAP and ..
Media ServersFilters
Session ServerXGSP-based Control
NaradaBrokeringAll Messaging
Use Multiple Media servers to scale to many codecs and manyversions of audio/video mixing
NB Scales asdistributed
WebServices
NaradaBrokering
A/V Collaboration Systems H323
H.323 is defined as an umbrella standard specifying the components to be used within an H.323-based environment.
SIPThe Session Initiation Protocol (SIP) defines how to establish, maintain and terminate Internet sessions including multimedia conferences
Access Grid enhanced Mbone A/V tools ( VIC, RAT )
Internet 2 network ( Multicast support )
XGSP Collaboration Framework To integrate heterogeneous systems into one
collaboration system• A unified, scalable, robust “overlay” network is needed to
support A/V and data group communication over heterogeneous networking environments.
• A common A/V signaling protocol has to be designed to support interactions between different A/V collaboration endpoints.
• Different A/V endpoints should collaborate in the same collaboration session.
Group Communication in Collaboration Collaboration applications usually need a group
communication service for both multipoint data and control information delivery• Centralized conferencing systems usually depend upon a
single conference server • Distributed conferencing systems use IP multicast Access Grid uses Internet2 multicast for audio/video
transmission. • Problems: Centralized conferencing systems don’t have good
scalability and IP multicast has not become ubiquitously available
We use distributed NaradaBrokering to provide this communication
A/V Collaboration over publish/subscribe Middleware video streams (VS) VS {v1, v2, … vm }
audio streams (AS) AS { a1, a2, … an }
A/V endpoints: E1, E2, … El
Each endpoint may send a single or multiple video streams, but only send an audio stream
Different types of A/V endpoints have different collaboration capabilities. • Multicast endpoints are able to receive multiple video and audio
streams, display all the video streams in their screens, and mix all the audio streams by themselves
• Unicast endpoints like Polycom Via Video can only receive and play a single video and audio stream
Publish/subscribe of A/V A stream in VS and AS is regarded as a “topic” Each RTP packet from this stream is regarded as an
“event” for this topic Only the sender of this stream can “publish” A/V events
to this topic Other endpoints need to subscribe to this topic in order
to receive the stream data Create mixed video and audio stream topics for unicast
endpoints
RTP packets encapsulation RTPLink: RTP Packets map to Narada Brokering
Event Every legacy A/V client needs one corresponding
RTPLink to be set up at a broker within broker network.
Unicast RTPLink: Integer Topic Numbers for RTP and RTCP
Multicast RTPLink:
A reflector between NaradaBrokers and multicast groups, encapsulating raw RTP packets from a multicast IP address to RTP events, publishing these events to NaradaBrokers, and forwarding the data it receives from broker network on the same IP address
Audio Mixer, Video Mixer, Image Grabber Audio Mixing
The audio mixer creates a mixed audio stream from all the audio streams in the session
Video Mixing Video mixing makes the unicast users watch the pictures of
multiple participants in a meeting through one video stream Video Thumbnail visualize the VS set in the session, embedded into the control panel
of each endpoint, which Image grabbers capture video streams and save them as static JPEG
files. All the media processing components can be distributed among
the pool of the media servers connected to NaradaBrokering infrastructures.
This generalizes to a farm of “stream servers” doing image processing etc.
H.323, SIP Gateway Servers, A/V Session Server H.323 and SIP gateway transform these protocol
specific messages into XGSP signaling messages so that H.323 and SIP A/V endpoints could communicate with the XGSP A/V session server
The session server implements session management logics • creating/destroying A/V sessions
• allowing endpoints to join/leave session
• Allowing users to make audio/video selection, managing A/V application components
Note Session Server very similar to Context Server in WS-Context
0
10
20
30
40
50
60
0 200 400 600 800 1000 1200 1400 1600 1800 2000
De
lay
(Mill
ise
con
ds)
Packet Number
Average delays per packet for 50 video-clients NaradaBrokering Avg=2.23 ms, JMF Avg=3.08 ms
NaradaBrokering-RTP JMF-RTP
0
1
2
3
4
5
6
7
8
0 200 400 600 800 1000 1200 1400 1600 1800 2000
Jitte
r (
Mill
ise
con
ds)
Packet Number
Average jitter (std. dev) for 50 video clients.
NaradaBrokering Avg=0.95 ms, JMF Avg=1.10 ms
NaradaBrokering-RTP JMF-RTP
Polycom view of multiple video streams
Polycom, Access Grid and RealVideo views of multiple streams using CGL A/V Web Service
integrating SIP and H323
Unicast AG Portlet
Application Web Servicesand Universal Access
NaradaBrokering can link lightweight clients (V in MVC) to Web Services holding as a Web service the “guts of an application” (M in MVC)• This allows customizable user interfaces gotten by mapping
between client profile protocols at NB
• Supports collaboration between diverse clients
Client1
Client2
M
Agent1
Agent2
ProfilesNB
P1
P2
P
Map P to P1
Map P to P2
Web Service
Integration of PDA, Cell phone and Desktop Grid Access