NaradaBrokering Grid Messaging and Applications as Web Services by vev19514

VIEWS: 46 PAGES: 69

									     NaradaBrokering
   Grid Messaging and
Applications as Web Services
            Geoffrey Fox
       Presenter: Marlon Pierce
        Community Grids Lab
          Indiana University
           gcf@indiana.edu
 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
                                                           Audio/Video

NaradaBrokering                                         Conferencing Client




                               Computer
                                          Modem                                             Server
                                                                                                     Web Service B

                                                                                                         Peers
                               NaradaBrokering Broker
   Minicomputer                       Network


                 Firewall
                                                                                                  Queues


 Stream




   Workstation                                                                        Laptop computer
                                 Peers


                            Web Service A                          Audio/Video
                                                                Conferencing Client
                                                  PDA
    “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
                 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
                                            SOAP+HTTP
                                            GridFTP
                                            RTP ….
  Standard client-server
                              Consumer                         Service
  style communication.


Substrate mediated
communication removes                           SOAP+HTTP         Service
                               Consumer         GridFTP
transport protocol dependence.                  RTP ….


                                           Messaging Substrate
                                         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
                          NB Brokers                     Fast
                                           Firewall      Link      B1
                         Satellite         HTTP
     A
                           UDP
                                                           Hand-Held
                                                                             B2
                                                             Protocol
                   Software Multicast
                                                      Dial-up
    NB Broker               Client Filtering                            B3
                                                      Filter
               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
                           Broker            Monitoring            Broker
    intervals can          Node              Service               Node
    also be varied
   Monitoring Service,           Link
                                  Data
                                                              Link
                                                              Data
    returns measured
    metrics to                      Aggregates info
                                                                    Control Message
                                     from nodes in a
    Performance                       certain domain
                                                                       Exchange

    Aggregator.                           Performance Aggregation
                                                      Service
    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                                        Hypercube of
                                                   NB Brokers (logical
                                                   not physical)



                                                            N≈100 for
                                                            Distance
                                                            Education
                                                            Per edge
                                                            Broker
                                                            Scale with
                                                            distributed
         1-> N Grid Clients                                 Broker 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.
                                     Mean transit delay for message samples in
                                   NaradaBrokering: Different communication hops
                               9
                                    hop-2
Transit Delay (Milliseconds)



                               8    hop-3
                               7    hop-5
                                    hop-7
                               6
                               5
                               4
                               3
                               2
                               1
                               0
                                        100                  1000          Pentium-3, 1GHz,
                                           Message Payload Size (Bytes)    256 MB RAM
                                                                           100 Mbps LAN
                                                                           JRE 1.3 Linux
        Standard Deviation for message samples in NaradaBrokering
             Different communication hops - Internal Machines
0.8
                                                         hop-2
0.7                                                      hop-3
                                                         hop-5
                                                         hop-7
0.6

0.5

0.4

0.3

0.2

0.1

 0
 1000     1500    2000    2500    3000    3500    4000     4500     5000
                          Message Payload Size
                                (Bytes)
NaradaBrokering and JMS (Java Message Service)


       Low Rate; Small Messages   (commercial JMS)
    NaradaBrokering and JXTA Federation
                                                     High end "long lived"/
   Based on hybrid proxy that                       persistent resources

    acts as both Rendezvous
    peer (JXTA routers) and
    NaradaBrokering end-                                                       NARADA-
                                                                               JXTA proxy
    point.
                                                    NARADA
   No changes to JXTA core                        broker cloud
    or constraints on
    interactions
     • Change made to Rendezvous
       layer
   Peers are not aware that        Peers
    they interact with a                                              JXTA
                                   Dynamic/fluid
    Narada-JXTA proxy or           peer groups
                                                                      Rendezvous
                                                                      PEER
    Rendezvous peer.
 NB provides JXTA guaranteed long distance delivery
 NB federates multiple JXTA Peer Groups
               End-point Services in
              Native 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
                                                   1   Request permission to publish
                    6
                                                       Respond back with topic
       5                            7              2
                                                       key if authorized to publish
                8
                                                       Encrypt message with topic key
     Key                                               Compute Message Digest(MD)
 Management                                        3
                                                       Sign MD and message ID
 Center (KMC)                                          Publish Message
                        NaradaBrokering Broker
                                Cloud                  Verify Signature & Permissions
                               4                   4   Check integrity by verifying MD
                                                       Check ID for replay attacks

           1    2          3                       5   Request permission to subscribe

                                                       Respond back with topic key if
                                                   6
                                                       authorized to subscribe
                                                       Create subscription request
                Broker Node                            Compute Message Digest
                                                   7
                                                       Sign MD and message ID
                Entity (Publisher or Subscriber)
                                                       Issue Subscription request Message
                SSL encrypted
                                                        Verify Signature
                communications
                                                        Verify Permissions for Subscribing
Based on Message Level Security                    8
                                                        Check integrity by verifying MD
    Messages organized into topics                      Check ID for replay attacks
    Each topic has a separate key; Topics can be organized into sessions
  Functionality I            WebSphere MQ             Pastry    NaradaBrokering
                          (formerly MQSeries)
Maximum number Medium (MQ is based on Very large               Very large
of nodes hosting the the point-to-point model.
                     There is a limit on the
messaging            effectiveness of this mode in
infrastructure       large configurations).

JMS Compliant             Yes                   No             Yes
Guaranteed                Yes                   Yes            Yes
Messaging (Robust)

Support for routing       No                    Yes            JXTA and later
P2P Interactions                                               Gnutella
Support for Audio/Video   No                    No             Yes
Conferencing & raw RTP
clients
Communication through     Yes                   No             Yes
proxies and firewalls
Support for XPath         No                    Yes            Yes
queries/ subscriptions
end-to-end Security       Yes                   No             Yes
Network Performance       No                    No             Yes
Monitoring
 Functionality II         WebSphere MQ                 Pastry             NaradaBrokering
                       (formerly MQSeries)
Workflow Support       Yes                      No                       No
Support for P2P        No                       Yes (Squirrel)           No
distributed caching
Platforms or Hosting   35 different OS/         Supported on platforms   Platforms
Environments           platforms supported.     which support C#
                                                                         supporting Java 1.4
                       Also supports the Java   (Microsoft) or Java
                       Platform.                (Rice).                  (tunneling C++)
Maturity of            Extremely mature,        Fair                     Fair with some
Software               with very robust                                  “production” testing
                       diagnostic information

Transport              TCP, HTTP,               TCP, UDP                 TCP (Blocking and
Protocols              Multicast, SSL,                                   non-blocking), UDP,
Supported              SNA etc.                                          Multicast, HTTP,
                                                                         SSL, RTP, (GridFTP)
Multiple transport     Yes                      No                       Yes
protocols over
multiple hops.

Broker Network         No                       No                       In Progress
Design Interface
                  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-RM
                                  WS-Reliability


SOAP related issues               Is a SOAP based protocol, which has an HTTP binding which            WSRM provides an XML schema for elements needed to support the
                                  facilitates acknowledgements and faults to be issued over HTTP       reliable messaging framework. The specification provides a SOAP
                                  responses.                                                           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        URI based [RFC 2396]. No additional requirement. Messages within
                                  based on what is outlined in RFC2392.                                a sequence are identified based on message numbers.

Sequence              numbering   Starts at 0 for the first message in a group.                        Starts at 1 for the first message in a group.
initialization

Sequence numbering rollover       Generate a new group identifier and begin new sequence only after    No new sequences can be generated.
                                  receipt of last message in old sequence.                             MessageRollover fault is issued.

Presence     of     numbering     REQUIRED only for guaranteed ordering.                               Message number is REQUIRED for every message that needs to be
information and its relation to                                                                        delivered reliably.
delivery

Acknowledgements                  Can be sent upon receipt of messages, as a callback or in response   Acknowledgements can be based on a range of messages, and the
                                  to a poll. Needed upon receipt of every message.                     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            AckRequested is used to request the receiving entity            to
                                  which reliable delivery needs to be ensured.                         acknowledge the message received. This is not REQUIRED.

Correlation associated with an    The identifier associated with the message being acknowledged.       The identifier associated with the sequence of messages and the
Acknowledgement                                                                                        message number within that sequence.

Timestamps                        Are expressed as UTC and conforms to a [XML Schema Part2: Data       No explicit reference to UTC. Uses the dateTime format.
                                  Types] dateTime element.

Retransmissions                   Triggered after receipt of a set of acknowledgements. In the event   Allows the specification of a RetransmissionInterval for a
                                  an acknowledgement is not received, the message is retransmitted     sequence (effects every message in the sequence). The interval can
                                  until a specified number of resend attempts have been made.          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.                    At most once, at least once and exactly once. Order is not
                                  Order is always tied to guaranteed delivery and cannot be            necessarily tied to guaranteed delivery.
                                  separately specified.


Security                          Relies on WS-Security and assorted specifications                    Relies on WS-Security and assorted specifications

Fault Codes      supported   by   InvalidMessageHeader                                                 SequenceTerminated
protocol                          Invalid MessageIdentifier                                            Unknown Sequence
                                  InvalidReferenceToMessageId                                          InvalidAcknowledgement
                                  InvalidTimeStamp                                                     MessageNumberRollover
                                  InvalidExpiryTime                                                    LastMessageNumberExceeded
                                  InvalidReliableMessage
                                  InvalidAckRequested
                                  InvalidMessageOrder
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
  • 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.


                          offset variations versus elapsed time                                         offset variations versus elapsed time
                                                                                                         3
  offset change - msecs




                                                                                offset change - msecs
                            3
                            2                                                                            2
                            1                                                                            1
                            0                                                                            0
                            1.07E+1   1.07E+1 1.07E+1 1.07E+1 1.07E+1 1.07E+1                           1.072E+1 1.072E+1 1.072E+1 1.073E+1 1.073E+1 1.073E+1
                           -1                                                                           -1 2         2        2        2        2        2
                               2         2       2       2       2       2
                           -2                                                                           -2
                           -3                                                                           -3
                           -4
                                                                                                        -4
                                local computer time - msecs                                                  local computer time - msecs


• 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.
               Building PSE’s with the
               Rule of the Millisecond I
   Typical Web Services are used in situations with interaction delays
    (network transit) of 100’s of milliseconds
   But basic message-based interaction architecture only incurs
    fraction of a millisecond delay
   Thus use Web Services to build ALL PSE components
     • Use messages and NOT method/subroutine call or RPC
   This “rule” OFTEN violated – people use “Java Interfaces” and so
    cannot distribute services

                                  Interaction

                       Nugget1                  Nugget2



                  Nugget3                  Nugget4
                                                           Data
               Building PSE’s with the
               Rule of the Millisecond II
   Messaging has several advantages over scripting languages
     • Collaboration trivial by sharing messages
     • Software Engineering due to greater modularity
     • Web Services do/will have wonderful support
   “Loose” Application coupling uses workflow technologies
   Find characteristic interaction time (millisecond programs;
    microseconds MPI and particle) and use best supported
    architecture at this level
     • Two levels: Web Service (Grid) and
       C/C++/C#/Fortran/Java/Python
   Major difficulty in frameworks is NOT building them but rather in
    supporting them
     • IMHO only hope is to always minimize life-cycle support risks
     • Science is too small a field to support much!
   Expect to use DIFFERENT technologies at each level even though
    possible to do everything with one technology
     • Trade 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)`;

                   y1     z1           p


                                       q       storage1
        x


                   y2     z2        storage2

                  NaradaBrokering Topic (Queue)

   Note this approach allows for example all workflow
    streams to use RMI, GridFTP, RTP – your or rather
    NaradaBrokering’s choice
          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.
                                             Subscribe
                       Pub/Sub Queue
       Publish
         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



    NB Brokers




                 Gridlets

      Grid formed from
      Multiple 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 Paradigm
       Model View Controller


                    Model

Controller

Mouse event         View
Keyboard events
                                Display

           Figure   MVC Model
        Web Service Model for Application Development
Data     Resource Facing Ports

       Application as a Web service
       W3C DOM Semantic Events
                                           Model
                                                            Narada
              User Facing                                  Brokering
                 Ports
       Events as       Rendering as
       Messages         Messages           Control


                                                             Natural in
         W3C DOM Raw (UI) Events
                                                             MVC Model

          W3C DOM User Interface            View

Interrupts in traditional monolithic applications become
“real messages” not directly method calls
Natural for collaboration and universal access
      Control flow for SVG As A Web
 Collaborative collaborative SVG clients Service
    From                                  Application as a Web service
    Collaboration                          Application as a Web service
    As a WS
                                            Events                Rendering
                          From Master

NaradaBrokering
                                                     W3C DOM Events

                                                      User Interface
    Participating Client


     From                                Application as a Web service
     Collaboration                        Application as a Web service
     As a WS
                                          Events                Rendering

              To Collaborative Clients

                                                W3C DOM Events

                                                     User Interface
    Master Client
Collaborative SVG Chess
 Game in Batik Browser
                      Players




                                Observers
Shared Output Port Collaboration
                                          Collaboration as a WS
  Web Service Message                   Set up Session with XGSP
  Interceptor

                                                            Master
              WSDL
      R                       U
  F                               F              WS           WS
           Application or
  I       Content source          I
                                               Viewer       Display
      O                       O
          Web Service


                                                WS           WS
Text Chat                                      Viewer       Display
Whiteboard
Multiple                      Event                         Other
masters                     (Message)                    Participants
                             Service
                                                WS            WS
                                               Viewer       Display
                  SIMD Collaboration
                            Non Web Service
                             Implementation
                          NaradaBrokering
     SVG                SVG                SVG                SVG
    Browser            Browser            Browser            Browser
Identical Programs receiving identical events
Token determines if browser is moving, waiting for opponent or an observer



                      SVG Model (DOM)               Shared Output port
                                                    SIMD Collaborative
                        NaradaBrokering             Web Service

    SVG                SVG                SVG                SVG
   Viewer             Viewer             Viewer             Viewer
Shared Input Port (Replicated WS) Collaboration
                                    Collaboration as a WS
                                  Set up Session with XGSP

                     R     U
                 F    Web     F
                     Servic            WS            WS
                 I     e      I      Viewer        Display
                   O        O

                                              Master

                     R     U
                 F    Web     F
                     Servic           WS            WS
  Event          I     e      I      Viewer        Display
                   O        O
(Message)
 Service
                                           Other
                                        Participants
                     R     U
                 F    Web     F
                     Servic           WS             WS
                 I     e      I      Viewer        Display
                   O        O
         MIMD Collaboration
             Shared Input port
             MIMD Collaborative
             Web Service


             NaradaBrokering
 SVG        SVG          SVG      SVG
 Model      Model        Model    Model


             NaradaBrokering

 SVG        SVG           SVG      SVG
Viewer     Viewer        Viewer   Viewer
        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
    Use Multiple Media servers to scale to many codecs and many
    versions of audio/video mixing

       Session Server                            Media Servers
     XGSP-based Control            Web              Filters
                                 Services


                          NaradaBrokering
NB Scales as               All Messaging               High Performance (RTP)
distributed                                            and XML/SOAP and ..


  Admire            SIP           H323           Access Grid     Native XGSP

               Gateways convert to uniform XGSP Messaging
                               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.
   SIP
    The 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
                                Average delays per packet for 50 video-clients
                               NaradaBrokering Avg=2.23 ms, JMF Avg=3.08 ms
                60
                                                     NaradaBrokering-RTP
                                                                JMF-RTP
                50
Delay (Milliseconds)




                40

                30

                20

                10

                       0
                           0    200 400 600 800 1000 1200 1400 1600 1800 2000
                                            Packet Number
                                 Average jitter (std. dev) for 50 video clients.
                                NaradaBrokering Avg=0.95 ms, JMF Avg=1.10 ms
                        8
                                                        NaradaBrokering-RTP
                        7                                          JMF-RTP

                        6
Jitter (Milliseconds)




                        5
                        4
                        3
                        2
                        1
                        0
                            0    200 400 600 800 1000 1200 1400 1600 1800 2000
                                             Packet Number
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 Services
            and 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

        Map P to P1   P1       Agent1

Web Service                                             Client1

    M                 NB      Profiles
                 P
                                                          Client2
        Map P to P2   P2       Agent2
Integration of PDA, Cell phone and Desktop Grid Access

								
To top