Grids for Real-time and Streaming Applications - PowerPoint PPT Presentation

Loading...

PPT – Grids for Real-time and Streaming Applications PowerPoint presentation | free to download - id: 26eab7-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Grids for Real-time and Streaming Applications

Description:

Grids for Realtime and Streaming Applications – PowerPoint PPT presentation

Number of Views:42
Avg rating:3.0/5.0
Slides: 60
Provided by: gridsUcs
Category:
Tags: applications | ee | grids | mt | nico | real | streaming | time

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Grids for Real-time and Streaming Applications


1
Grids for Real-time and Streaming Applications
  • PPAM 2005 6th International Conference on
    Parallel Processing and Applied Mathematics
  • Poznan Poland
  • September 11-14 2005
  • Geoffrey Fox
  • Computer Science, Informatics, Physics
  • Pervasive Technology Laboratories
  • Indiana University Bloomington IN 47401
  • http//grids.ucs.indiana.edu/ptliupages/presentati
    ons/PPAMPoznanSep12-05.ppt
  • gcf_at_indiana.edu http//www.infomall.org

2
What to Remember
  • Grids are Services exchanging Messages
  • Developing messaging paradigm for Grids using
    Message Oriented Middleware or Software Overlay
    Network
  • Just as MPI is messaging/programming model for
    parallel computing
  • Web Service container replaces computer
  • Service replaces process
  • A stream is an ordered set of messages
  • NaradaBrokering replaces MPI with different
    applications and different requirements
  • Service Internet replaces Internet messages
    replace packets
  • (Sub)Grids replace Libraries

3
Four Application Areas
  • Data Assimilation applied to link the data deluge
    (satellites, sensors, seismometers) in real time
    to large scale parallel simulations
  • Department of Defense (and Homeland Security)
    have built the Global Information Grid with a
    target architecture NCOW (Network Centric
    Operations and warfare)
  • They submit no jobs rather stream data to
    brokers from they are filtered and distributed
  • Includes their rather dated distributed
    simulation HLA
  • Audio-Video Conferencing implemented with
    services and Grid messaging
  • Hand-held Grid linking PDA/cell-phones to Grids

4
NaradaBrokering
Brokers are likeRouters orNetwork Handlers
5
Typical use of Grid Messaging
Filter or Datamining
Sensor Grid
Post afterProcessing
Post beforeProcessing
Web Feature Service
NaradaBrokering
Notify
WFS (GIS data)
Database Archives
Subscribe
HPSearch Manages
GIS Grid
WS-Context Stores dynamic data
GeographicalInformation System
6
Traditional NaradaBrokering Features
Multiple protocol transport support In publish-subscribe Paradigm with different Protocols on each link Transport protocols supported include TCP,  Parallel TCP streams, UDP, Multicast, SSL, HTTP and HTTPS. Communications through authenticating proxies/firewalls NATs. Network QoS based Routing Allows Highest performance transport
Subscription Formats Subscription can be Strings, Integers, XPath queries, Regular Expressions, SQL and tagvalue pairs.
Reliable delivery Robust and exactly-once delivery in presence of failures
Ordered delivery Producer Order and Total Order over a message type. Time Ordered delivery using Grid-wide NTP based absolute time
Recovery and Replay Recovery from failures and disconnects. Replay of events/messages at any time. Buffering services.
Security Message-level WS-Security compatible security
Message Payload options Compression and Decompression of payloads Fragmentation and Coalescing of payloads
Messaging Related Compliance Java Message Service (JMS) 1.0.2b compliant Support for routing P2P JXTA interactions.
Grid Feature Support NaradaBrokering enhanced Grid-FTP. Bridge to Globus GT3.
Web Services supported Implementations of WS-ReliableMessaging, WS-Reliability and WS-Eventing.
7
(No Transcript)
8
(No Transcript)
9
Consequences of Rule of the Millisecond
  • Useful to remember critical time scales
  • 1) 0.000001 ms CPU does a calculation
  • 2a) 0.001 to 0.01 ms Parallel Computing MPI
    latency
  • 2b) 0.001 to 0.01 ms Overhead of a Method Call
  • 3) 1 ms wake-up a thread or process
    (do simple things on a PC)
  • 4) 10 to 1000 ms Internet delay
  • 2a), 4) implies geographically distributed
    metacomputing cant in general compete with
    parallel systems
  • 3) ltlt 4) implies a software overlay network is
    possible without significant overhead
  • We need to explain why it adds value of course!
  • 2b) versus 3) and 4) describes regions where
    method and message based programming paradigms
    important

10
RepositoriesFederated Databases
Streaming Data
Sensors
Database
Sensor Grid
Database Grid
Research
Education
SERVOGrid
Compute Grid
Customization Services From Researchto Education
Data FilterServices
ResearchSimulations
Analysis and VisualizationPortal
EducationGrid Computer Farm
Grid of Grids Research Grid and Education Grid
11
Databases and/or Sensors
OGSA-DAIGrid Services
AnalysisControl Visualize
Grid
Data
Filter
This Type of Grid integrates with Parallel
computing Multiple HPC facilities but only use
one at a time Many simultaneous data sources and
sinks
HPC Simulation
Grid Data Assimilation
Other Gridand Web Services
Distributed Filters massage data For simulation
SERVOGrid (Complexity) Computing Model
12
GIS and Sensor Grids
  • OGC has defined a suite of data structures and
    services to support Geographical Information
    Systems and Sensors
  • GML Geography Markup language defines
    specification of geo-referenced data
  • SensorML and OM (Observation and Measurements)
    define meta-data and data structure for sensors
  • Services like Web Map Service, Web Feature
    Service, Sensor Collection Service define
    services interfaces to access GIS and sensor
    information
  • Grid workflow links services that are designed to
    support streaming input and output messages
  • We are building Grid (Web) service
    implementations of these specifications for
    NASAs SERVOGrid

13
A Screen Shot From the WMS Client
14
WMS uses WFS that uses data sources
ltgmlfeatureMembergt ltfaultgt ltnamegt
Northridge2 lt/namegt ltsegmentgt Northridge2
lt/segmentgt ltauthorgt Wald D. J.lt/authorgt
ltgmllineStringPropertygt
ltgmlLineString srsName"null"gt
ltgmlcoordinatesgt -118.72,34.243
-118.591,34.176 lt/gmlcoordinatesgt
lt/gmlLineStringgt lt/gmllineStringPropertygt
lt/faultgt lt/gmlfeatureMembergt
15
Example of Data Mining and GIS Grid
Data Mining Grid
Databases with NASA, USGS features SERVOGrid
Faults
NASA WMS
WFS2
WFS1
WFS3
WMS handling Client requests
UDDI
SOAP
HTTP
WMS Client
WMS Client
16
Data Mining Grid from Grid of Grids
Databases with NASA,USGS features SERVOGrid
Faults
WFS4
SOAP
Pipeline
UDDI
HPSearchWorkflow
Traditional Execution Grid
NaradaBrokering
System Services
17
Hot spots calculations--areas of increased
earthquake probability in the forecast time--
calculations are re-plotted on the map as
features.
18
Raw to GML via NaradaBrokering
  • The Scripps Orbit and Permanent Array Center
    (SOPAC) GPS station network data published in RYO
    format is converted to ASCII and GML

19
Typical use of Grid Messaging in NASA
Sensor Grid
GIS Grid
Grid Eventing
Datamining Grid
20
Google Map Client
Archived
Real Time
Google Central
Databases withSERVOGrid Faults
Sensor Grid
HTTP
WFS2
WFS1
Google Map Client
Helper Services
SOAP
DoD and Homeland Security can in a crisis combine
custom geo-referenced data with that available
from hundreds of thousands of computers from
Microsoft, Yahoo and Google Just build simple
services using Interoperability standards!
UDDI
21
Real Time GPS and Google Maps
Subscribe to live GPS station. Position data from
SOPAC is combined with Google map clients.
Select and zoom to GPS station location, click
icons for more information.
22
Integrating Archived Web Feature Services and
Google Maps
Google maps can be integrated with Web Feature
Service Archives to filter and browse seismic
records.
23
Google Maps as Service accessed from our WMS
Client
24
Grid Principles Needed I
  • Data deluge and Data Assimilation
  • Web Services used for all capabilities to achieve
    interoperability and sustainability
  • High performance Service containers and handlers
  • Service Architectures OGSA (GGF) or NCOW (DoD)
  • Grids composed hierarchically in Grid of Grids
    approach to Grid libraries
  • Gateways linking Grids to legacy systems or to
    other Grids
  • Sessions which are the dynamic grouping of
    (10-1000) services involved in solving a problem
    to be distinguished from the huge Grid-world over
    which information is slowly varying
  • Registries and metadata Services
  • Need to optimized for both Grid-world (worldwide
    scaling) and Sessions (update times of a few
    milliseconds)

25
Grid Principles Needed II
  • Interoperability through protocols and interfaces
  • A major reason we are doing this and unlike MPI
  • Difference between semantics and representation
  • and consequence for interoperability
  • Law of the Millisecond
  • Use Grid messaging if latencies are inevitably gt
    1ms
  • Distributed management of Streams (messages) for
    performance and QoS
  • Must not centralize streams or their management
  • Workflow of Services and Composition of Streams
  • Services and Messages are both first class
    entities
  • Our workflow challenges simple compared to other
    projects

26
WFS OGSA-DAI etc.
  • The Web Feature Service WFS from OGC (Open
    Geospatial Consortium) is a domain specific
    database holding data or meta-data
  • It provides a GML (Geography Markup Language)
    interface to a MySQL database
  • It filters GML store and GML query requests into
    SQL
  • XML databases are currently much slower than this
    strategy
  • Example of Semantics (XML) versus representation
    (SQL) difference
  • OGSA-DAI offers Grid interface to databases we
    could use but dont as we only need to expose WFS
    and not MySQL to Grid

27
Role of WS-Context
  • There are many WS- specifications addressing
    meta-data and both many approaches and many
    trade-offs
  • We hear about Distributed Hash Tables (Chord) to
    achieve scalability in large scale networks
  • Managed dynamic workflows as in sensor
    integration and collaboration require
  • Fault-tolerance and ability to support dynamic
    changes with few millisecond delay
  • But only a modest number of involved services (up
    to 1000s in a session)
  • Need Session NOT Service/Resource meta-data so
    dont use WS-RF
  • We are building a WS-Context compliant metadata
    catalog supporting distributed or central
    paradigms
  • Use for OGC Web catalog service with UDDI for
    slowly varying meta-data
  • 3 XML Databases UDDI WS-Context WFS stored as SQL

28
Controlling Streaming Data
  • NaradaBrokering capabilities can be created by
    messages (as in WS-) and by a scripting
    interface that allows topics to be created and
    linked to external services
  • Firewall traversal algorithms and network link
    performance data can be accessed
  • HPSearch offers this via JavaScript
  • This scripting engine provides a simple workflow
    environment that is useful for setting up Sensor
    Grids
  • Should be made compatible with Web Service
    workflow (BPEL) and streaming workflow models
    Triana and Kepler
  • Using WS-Management as interaction protocol

29
SOAP Message Structure I
  • SOAP Message consists of headers and a body
  • Headers could be for Addressing, WSRM, Security,
    Eventing etc.
  • Headers are processed by handlers or filters
    controlled by container as message enters or
    leaves a service
  • Body processed by Service itself
  • The header processing defines the Web Service
    Distributed Operating System
  • Containers queue messages control processing of
    headers and offer convenient (for particular
    languages) service interfaces
  • Handlers are really the core Operating system
    services as they receive and give back messages
    like services they just process and perhaps
    modify different elements of SOAP Message WS
    standards specify handler structure

30
The Ten areas covered by the core WS-
Specifications
WS- Specification Area Examples
1 Core Service Model XML, WSDL, SOAP
2 Service Internet WS-Addressing, WS-MessageDelivery Reliable Messaging WSRM Efficient Messaging MOTM
3 Notification WS-Notification, WS-Eventing (Publish-Subscribe)
4 Workflow and Transactions BPEL, WS-Choreography, WS-Coordination
5 Security WS-Security, WS-Trust, WS-Federation, SAML, WS-SecureConversation
6 Service Discovery UDDI, WS-Discovery
7 System Metadata and State WSRF, WS-MetadataExchange, WS-Context
8 Management WSDM, WS-Management, WS-Transfer
9 Policy and Agreements WS-Policy, WS-Agreement
10 Portals and User Interfaces WSRP (Remote Portlets)
31
Application Specific Grids Generally Useful
Services and Grids Workflow WSFL/BPEL Service
Management (Context etc.) Service Discovery
(UDDI) / Information Service Internet Transport ?
Protocol Service Interfaces WSDL
Higher Level Services
ServiceContext
ServiceInternet
Base Hosting Environment
Protocol HTTP FTP DNS Presentation XDR
Session SSH Transport TCP UDP Network IP
Data Link / Physical
Bit level Internet (OSI Stack)
Layered Architecture for Web Services and Grids
32
WS- implies the Service Internet
  • We have the classic (CISCO, Juniper .) Internet
    routing the flood of ordinary packets in OSI
    stack architecture
  • Web Services build the Service Internet or IOI
    (Internet on Internet) with
  • Routing via WS-Addressing not IP header
  • Fault Tolerance (WS-RM not TCP)
  • Security (WS-Security/SecureConversation not
    IPSec/SSL)
  • Data Transmission by WS-Transfer not HTTP
  • Information Services (UDDI/WS-Context not
    DNS/Configuration files)
  • At message/web service level and not packet/IP
    address level
  • Software-based Service Internet possible as
    computers fast
  • Familiar from Peer-to-peer networks and built as
    a software overlay network defining Grid (analogy
    is VPN)
  • SOAP Header contains all information needed for
    the Service Internet (Grid Operating System)
    with SOAP Body containing information for Grid
    application service

33
Merging the OSI Levels
  • All messages pass through multiple operating
    systems and each O/S thinks of message as a
    header and a body
  • Important message processing is done at
  • Network
  • Client (UNIX, Windows, J2ME etc)
  • Web Service Header
  • Application
  • EACH is lt 1ms (except forsmall sensor clients
    andexcept for complex security)
  • But network transmissiontime is often 100ms or
    worse
  • Thus no performance reasonnot to mix up places
    processingdone

IP
TCP
App
SOAP
34
What is a Simple Service?
  • Take any system it has multiple functionalities
  • We can implement each functionality as an
    independent distributed service
  • Or we can bundle multiple functionalities in a
    single service
  • Whether functionality is an independent service
    or one of many method calls into a glob of
    software, we can always make them as Web
    services by converting interface to WSDL
  • Simple services are gotten by taking
    functionalities and making as small as possible
    subject to rule of millisecond
  • Distributed services incur messaging overhead of
    one (local) to 100s (far apart) of milliseconds
    to use message rather than method call
  • Use scripting or compiled integration of
    functionalities ONLY when require lt1 millisecond
    interaction latency
  • Apache web site has many (pre Web Service)
    projects that are multiple functionalities
    presented as (Java) globs and NOT (Java) Simple
    Services
  • Makes it hard to integrate globs sharing common
    security, user profile, file access .. services

35
Grids of Grids of Simple Services
  • Link via methods ? messages ? streams
  • Services and Grids are linked by messages
  • Internally to service, functionalities are linked
    by methods
  • A simple service is the smallest Grid
  • We are familiar with method-linked
    hierarchyLines of Code ? Methods ? Objects ?
    Programs ? Packages

36
Component Grids
  • So we build collections of Web Services which we
    package as component Grids
  • Visualization Grid
  • Sensor Grid
  • Management Grid
  • Utility Computing Grid
  • Collaboration Grid
  • Earthquake Simulation Grid
  • Control Room Grid
  • Crisis Management Grid
  • Intelligence Data-mining Grid
  • We build bigger Grids by composing component
    Grids using the Service Internet

37
Gas CIGrid
Earthquake Grid


Gas Servicesand Filters
Earthquake Data Simulation Services
Portals
Visualization Grid
Collaboration Grid
Sensor Grid
Compute Grid
GIS Grid
Data Access/Storage
Registry
Metadata
Core Grid Services
Physical Network
Critical Infrastructure (CI) Grids built as Grids
of Grids
38
Google plus GIS Grid Integratedwith Los Alamos
CI Simulations for DHS
Natural Gas Layer
Energy Power Layer
39
Mediation and Transformation in a Grid of Grids
and Simple Services
40
The Global Information Grid Core Enterprise
Services
Core Enterprise Services Service Functionality
CES1 Enterprise Services Management (ESM) including life-cycle management
CES2 Information Assurance (IA)/Security Supports confidentiality, integrity and availability. Implies reliability and autonomic features
CES3 Messaging Synchronous or asynchronous cases
CES4 Discovery Searching data and services
CES5 Mediation Includes translation, aggregation, integration, correlation, fusion, brokering publication, and other transformations for services and data. Possibly agents
CES6 Collaboration Provision and control of sharing with emphasis on synchronous real-time services
CES7 User Assistance Includes automated and manual methods of optimizing the user GiG experience (user agent)
CES8 Storage Retention, organization and disposition of all forms of data
CES9 Application Provisioning, operations and maintenance of applications.
41
Activities in Global Grid Forum Working Groups
GGF Area Standards Activities
1 Architecture High Level Resource/Service Naming (level 2 of fig. 1), Integrated Grid Architecture
2 Applications Software Interfaces to Grid, Grid Remote Procedure Call, Checkpointing and Recovery, Interoperability to Job Submittal services, Information Retrieval,
3 Compute Job Submission, Basic Execution Services, Service Level Agreements for Resource use and reservation, Distributed Scheduling
4 Data Database and File Grid access, Grid FTP, Storage Management, Data replication, Binary data specification and interface, High-level publish/subscribe, Transaction management
5 Infrastructure Network measurements, Role of IPv6 and high performance networking, Data transport
6 Management Resource/Service configuration, deployment and lifetime, Usage records and access, Grid economy model
7 Security Authorization, P2P and Firewall Issues, Trusted Computing
42
DoD Core Services and WS- plus OGSA I
NCOW Service or Feature WS- Service area GGF Others
A General Principles A General Principles A General Principles A General Principles
Use Service Oriented Architecture Core Service Model (1) Build Grids on Web Services Industry Best Practice (IBM, Microsoft )
Grid of Grids Composition Strategy for legacy subsystems and modular architecture
B NCOW Core Services (to be continued) B NCOW Core Services (to be continued) B NCOW Core Services (to be continued) B NCOW Core Services (to be continued)
CES 1 Enterprise Services Management WS- 8 Management GGF 6 Management CIM
CES 2 Information Assurance(IA)/Security WS- 5 WS-Security GGF 7, Grid-Shib, Permis Liberty Alliance etc.
CES 3 Messaging WS- 2, 3 JMS, MQSeries,Streaming /Sensor Technologies
CES 4 Discovery WS- 6
CES 5 Mediation WS- 4 workflow Treatment of Legacy systems. Data Transformations
CES 6 Collaboration VO GGF VO. XGSP, Shared Web Service ports
CES 7 User assistance WS- 10 Portlets, JSR168NCOW Capability Interfaces
43
DoD Core Services WS- and OGSA II
NCOW Service or Feature WS- Service area GGF Others
B NCOW Core Services Continued B NCOW Core Services Continued B NCOW Core Services Continued B NCOW Core Services Continued
CES 8 Storage (not real-time streams) GGF 4 Data NCOW Data Strategy
CES 9 Application GGF 2 Best Practice in building Grid/Web services
Environmental Control Services ECS WS-, 9
Resource Infrastructure GGF 5 giG itself Ad-hoc networks important
C Key NCOW Capabilities not directly in CES C Key NCOW Capabilities not directly in CES C Key NCOW Capabilities not directly in CES C Key NCOW Capabilities not directly in CES
Meta-data WS- 7 Semantic Grid Globus MDS Semantic Web Annotation
Resource/Service Matching/Scheduling Distributed Scheduling and SLAs (GGF 3) GGF scheduling work extended to networks Extend computer scheduling to networks and data flow
Sensors (real-time data) OGC Sensor standards
GIS OGC GIS standards
44
SOAP Message Structure II
  • Content of individual headers and the body is
    defined by XML Schema associated with WS-
    headers and the service WSDL
  • SOAP Infoset captures header and body structure
  • XML Infoset for individual headers and the body
    capture the details of each message part
  • Web Service Architecture requires that we capture
    Infoset structure but does not require that we
    represent XML in angle bracket ltcontentgtvaluelt/con
    tentgt notation

Infoset representssemantic structure of message
and itsparts
45
High Performance XML I
  • There are many approaches to efficient binary
    representations of XML Infosets
  • MTOM, XOP, Attachments, Fast Web Services
  • DFDL is one approach to specifying a binary
    format
  • Assume URI-S labels Scheme and URI-R labels
    realization of Scheme for a particular message
    i.e. URI-R defines specific layout of information
    in each message
  • Assume we are interested in conversations where a
    stream of messages is exchanged between two
    services or between a client and a service i.e.
    two end-points
  • Assume that we need to communicate fast between
    end-points that understand scheme URI-S but must
    support conventional representation if one
    end-point does not understand URI-S

46
High Performance XML II
  • First Handler FtF1 handles Transport protocol
    it negotiates with other end-point to establish a
    transport conversation which uses either HTTP
    (default) or a different transport such as UDP
    with WSRM implementing reliability
  • URI-T specifies transport choice
  • Second Handler FrF2 handles representation and
    it negotiates a representation conversation with
    scheme URI-S and realization URI-R
  • Negotiation identifies parts of SOAP header that
    are present in all messages in a stream and are
    ONLY transmitted ONCE
  • Fr needs to negotiate with Service and other
    handlers illustrated by F3 and F4 below to decide
    what representation they will process

47
High Performance XML III
  • Filters controlled by Conversation Context
    convert messages between representations using
    permanent context (metadata) catalog to hold
    conversation context
  • Different message views for each end point or
    even for individual handlers and service within
    one end point
  • Conversation Context is fast dynamic metadata
    service to enable conversions
  • NaradaBrokering will implement Fr and Ft using
    its support of multiple transports, fast filters
    and message queuing

Conversation ContextURI-S, URI-R,
URI-T Replicated Message Header
Transported Message
Handler Message View
ServiceMessage View
Service
48
Web Service Collaboration
Shared Output port with replicated recipients
Shared Input Port with replicated services
49
Pipelined Web Service Collaboration
  • In a workflow, one can invoke collaborative
    streams on any flow and this splitting is between
    output port of one and input of next Web Service
    in chain

WS-B
WS-A
Shared Output Port
Shared Input Port
50
Collaboration Grid
XGSP Media Service
WS-Context
NaradaBroker
Audio Mixer
HPSearch
Video Mixer
UDDI
NaradaBroker
Transcoder
Thumbnail
WS-Security
Replay
NaradaBroker
Record
Annotate
SharedWS
SharedDisplay
WhiteBoard
51
GlobalMMCS SWT Client
TV
GIS
Chat
Webcam
Video Mixer
52
eAnnotationPlayer
eAnnotationWhiteBoard
53
PDA Download video (using 4-way video mixer
service)
Desktop
PDA
54
Average Video Delays for one broker Performance
scales proportional to number of brokers
55
Multiple Brokers Multiple Meetings
  • 4 brokers can support 48 meetings with 1920 users
    in total with excellent quality.
  • This number is higher than the single video
    meeting tests in which four brokers supported up
    to 1600 users.
  • When we repeated the same test with meeting size
    20, 1400 participants can be supported.

Number of Meetings Total users Broker1 (ms) Broker2 (ms) Broker3 (ms) Broker4 (ms)
40 1600 3.34 6.93 8.43 8.37
48 1920 3.93 8.46 14.62 10.59
60 2400 9.04 170.04 89.97 25.83
Latency for meeting size 40
Number of Meetings Total users Broker1 () Broker2 () Broker3 () Broker4 ()
40 1600 0.00 0.00 0.00 0.00
48 1920 0.12 0.29 0.50 0.50
60 2400 0.16 1.30 2.51 2.82
loss rates
56
(No Transcript)
57
What do I know that could be interesting
  • SERVOGrid Database/sensor driven Grid for
    Earthquake Science driving data-mining and
    simulation
  • Data-mining is data assimilation with so much
    complication in simulation?
  • Geographical Information System (GIS) component
    Grid to illustrate Grid of Grids
  • GlobalMMCS Access Grid/Polycom built from
    Services
  • Real-time Annotation service applicable to
    e-Sports, Surveillance, Scientific discovery
  • Core Technology Messaging that supports SOAP and
    high performance transport for data streams and
    PDAs
  • Integration with Web Service Containers and
    Handlers
  • Message and Stream Management Service
  • Dynamic meta-data services for sessions
  • DoD NCOW Comparison with OGSA

58
NB Features Released 2005-2006
  • Production implementations of WS-Eventing, WS-RM
    and WS-Reliability.
  • WS-Notification when specification agreed
  • SOAP message support and NaradaBrokers viewed as
    SOAP Intermediaries
  • Active replay support Pause and Replay live
    streams.
  • Stream Linkage can link permanently multiple
    streams using in annotating real-time video
    streams
  • Replicated storage support for fault tolerance
    and resiliency to storage failures.
  • Management HPSearch Scripting Interface to
    streams and brokers (uses WS-Management)
  • Broker Topics and Message Discovery Locate
    appropriate
  • Integration with Axis2 Web Service Container (?)
  • Support of IBM MQSeries functionality and Legacy
    MQSeries Systems as a Grid of Grids gateway
  • Better Security tracking endless changes of
    WS-Security
  • High Performance Transport supporting SOAP Infoset

59
Location of software for Grid Projects in
Community Grids Laboratory
  • htpp//www.naradabrokering.org provides Web
    service (and JMS) compliant distributed
    publish-subscribe messaging (software overlay
    network)
  • htpp//www.globlmmcs.org is a service oriented
    (Grid) collaboration environment (audio-video
    conferencing)
  • http//www.crisisgrid.org is an OGC (open
    geospatial consortium) Geographical Information
    System (GIS) compliant GIS and Sensor Grid
  • http//www.opengrids.org has WS-Context, Extended
    UDDI etc.
  • The work is still in progress but NaradaBrokering
    is quite mature
  • All software is open source and freely available
About PowerShow.com