11

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/presentations/PPAMPoznanSep12-05.pptgcf@indiana.edu http://www.infomall.org

22

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

33

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

Stream

NB supports messagesand streams

NB role for Grid isSimilar toMPI role for MPP

Queues

NaradaBrokering

Brokers are likeRouters orNetwork Handlers

5

Typical use of Grid Messaging

HPSearchManages

NaradaBrokering

Sensor Grid

WS-ContextStores dynamic data

Filter orDatamining

WFS (GIS data)

Post beforeProcessing

Post afterProcessing

Notify

SubscribeDatabaseArchives

Web Feature Service

GIS Grid

GeographicalInformation System

6

Multiple protocol transport supportIn publish-subscribeParadigm with differentProtocols 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 RoutingAllows Highest performance transport

Subscription Formats Subscription can be Strings, Integers, XPath queries, Regular Expressions, SQL and tag=value 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 payloadsFragmentation 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.

Traditional NaradaBrokering Features

77

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

hop-3

Pentium-3, 1GHz, 256 MB RAM100 Mbps LAN

JRE 1.3 Linux

88

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

99

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 can’t in general compete with parallel systems

3) << 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

1010

Database Database

Analysis and VisualizationPortal

RepositoriesFederated Databases

Data Filter

Services

Field Trip DataStreaming Data

Sensors

?DiscoveryServices

SERVOGrid

ResearchSimulations

Research Education

CustomizationServices

From Research

to Education

EducationGrid ComputerFarmGrid of Grids: Research Grid and Education Grid

GISGrid

Sensor GridDatabase Grid

Compute Grid

1111

HPCSimulation

DataFilter

Data FilterD

ata

Filt

er

Data

Filter

Data

Filter

Distributed Filters massage dataFor simulation

Other

Grid

and W

eb

Servi

ces

AnalysisControl

Visualize

SERVOGrid (Complexity) Computing Model

Grid

OGSA-DAIGrid Services

This Type of Gridintegrates with

Parallel computingMultiple HPC

facilities but only use one at a time

Many simultaneous data sources and

sinks

Grid Data Assimilation

Databases and/or Sensors

1212

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 O&M (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 NASA’s SERVOGrid

1313

A Screen Shot From the WMS Client

1414

WMS uses WFS that uses data sources

Railroads

RiversBridges

Interstate Highways

90

WFS Server

SQL Query

Railroads

[a-b]

SQ

L Q

uery

Riv

er [a

-d]

Bri

dge

[1-5

]

SQL QueryHigway [12-18]

`

ClientWMS

GetFeature

FeatureCollection

Get

Feat

ure

Feat

ureC

olle

ctio

n

<gml:featureMember> <fault> <name> Northridge2 </name> <segment> Northridge2

</segment> <author> Wald D. J.</author> <gml:lineStringProperty> <gml:LineString

srsName="null"> <gml:coordinates>

-118.72,34.243 -118.591,34.176 </gml:coordinates>

</gml:LineString> </gml:lineStringProperty> </fault> </gml:featureMember>

15

Example of Data Mining and GIS Grid

WMS handlingClient requests

WMS Client

UDDI

WFS2

Databases withNASA, USGS features

SERVOGrid Faults

WFS1 NASA WMS

HTTP

SOAP

WFS3

Data Mining Grid

WMS Client

16

Data Mining Grid from Grid of Grids

HPSearch“Workflow”

UDDI

Databases withNASA,USGS features

SERVOGrid FaultsWFS4

SOAP

WS-Context

WFS3

PI Data Mining

Filter

GIS Grid

Filter

NaradaBrokering

Pipeline

System Services

TraditionalExecutionGrid

17

Hot spots calculations--areas of increased earthquake probability in the forecast time-- calculations are re-plotted on the map as features.

1818

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

Datamining Grid

Sensor Grid

Grid Eventing GIS Grid

20

Google Map Client

Google Central

Google Map Client

UDDI

WFS2

Databases withSERVOGrid Faults

WFS1

SOAP

Sensor Grid

HTTP

Helper Services

Archived Real Time

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!

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

Google maps can be integrated with Web Feature Service Archives to filter and browse seismic records.

Integrating Archived Web

Feature Services and Google Maps

23

Google Maps as Service

accessed from our WMS

Client

2424

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)

2525

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 > 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

2626

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 don’t as we only need to expose WFS and not MySQL to Grid

2727

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 1000’s

in a session)• Need Session NOT Service/Resource meta-data so don’t 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

2828

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

2929

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

H1 H4H3H2 Body F1 F2 F3 F4 Service

Container Handlers

Container Workflow

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

Bit levelInternet

(OSI Stack)

Layered Architecture for Web Services and Grids

Base Hosting EnvironmentProtocol HTTP FTP DNS …

Presentation XDR …Session SSH …

Transport TCP UDP …Network IP …

Data Link / Physical

ServiceInternet

Application Specific GridsGenerally Useful Services and Grids

Workflow WSFL/BPELService Management (“Context etc.”)

Service Discovery (UDDI) / InformationService Internet Transport Protocol

Service Interfaces WSDL

ServiceContext

HigherLevelServices

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

3333

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 < 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

SOAP

App

3434

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

100’s (far apart) of milliseconds to use message rather than method call

• Use scripting or compiled integration of functionalities ONLY when require <1 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 hierarchy

Lines of Code Methods Objects Programs Packages

Overlayand ComposeGrids of Grids

Methods Services Component Grids

CPUs Clusters ComputeResource Grids

MPPs

DatabasesFederatedDatabases

Sensor Sensor Nets

DataResource Grids

3636

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

3737

Critical Infrastructure (CI) Grids built as Grids of Grids

Gas Servicesand Filters

Physical Network

Registry Metadata

Earthquake Data& Simulation Services

Earthquake Grid Gas CIGrid… Electricity CIGrid …

Data Access/Storage

Security WorkflowNotification Messaging

Portals Visualization GridCollaboration Grid

Sensor Grid Compute GridGIS Grid

Core Grid Services

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

Po

rtP

ort

Port PortInternal

Interfaces

Subgrid or service

Po

rtP

ort

Port PortInternal

Interfaces

Subgrid or service

Po

rtP

ort

Port PortInternal

Interfaces

Subgrid or service

Messaging

Mediation andTransformationServices

External facingInterfaces

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 INCOW Service or Feature WS-* Service area GGF Others

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)

CES 1: Enterprise Services Management

WS-* #8 Management GGF #6: Management CIM

CES 2: Information Assurance(IA)/Security

WS-* #5WS-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 IINCOW Service or Feature WS-* Service area GGF Others

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

Meta-data WS-* #7 Semantic Grid

Globus MDS

Semantic Web; Annotation

Resource/Service Matching/Scheduling

Distributed Scheduling and SLA’s (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

4444

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 <content>value</content> notation

H1 H4H3H2 Body

bp1 bp2 bp3hp1 hp2 hp3 hp4 hp5

Infoset representssemantic structureof message and itsparts

4545

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

4646

High Performance XML II First Handler Ft=F1 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 Fr=F2 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

F1 F2 F3 F4

Container Handlers

4747

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;

H1 H4H3H2 Body

Service

Conversation ContextURI-S, URI-R, URI-T

Replicated Message Header

Transported Message Handler Message View

ServiceMessage View

Container Handlers

Ft Fr F3 F4

48

Web Service Collaboration

Web Service NaradaBrokering

WS1

WS2

WS3

NaradaBrokering

Shared Input Port with replicated services

Shared Output port with replicated recipients

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

WS1

WS2

WS3

NaradaBrokering

WS4

WS5

WS6

WS-BWS-A

Shared Input Port

Shared Output Port

50

Collaboration Grid

UDDI NaradaBroker

HPSearch

WS-Context

Gateway

WS-Security

NaradaBroker

NaradaBroker

Gateway

Gateway

Gateway

XGSP MediaService

Video Mixer

Transcoder

Audio Mixer

Replay

Record

Annotate

Thumbnail

WhiteBoard

SharedDisplay

SharedWS

51GlobalMMCS SWT Client

Chat

TV

WebcamVideo Mixer

GIS

5252

eSport Player Archived video player

Annotation/WB player

Archieved stream list

Real time stream list

Real time stream player

eSport Whiteboard

eAnnotationWhiteBoard

eAnnotationPlayer

5353

PDA Download video (using 4-way video mixer service)

PDA

Desktop

54

Average Video Delays for one broker – Performance scales proportional to number of brokers

Latency ms

# Receivers

One sessionMultiple sessions

30 frames/sec

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

Totalusers

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

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

Latency for meeting size 40

loss rates

5656

RTSP Streaming Servers

e-AnnotationPortal Server

Storage Servers

Collaborative Communication

Master/Coach

Student

Student

Student

NaradaBrokering

broker

broker

broker

broker

broker

TV

Capture Device

GLOBALMMCS

Archived Real Time Live VideoFrom TV and Capture Devices

Archived Video Clip Files

Video Annotation Snapshots

broker

Collaborative eSport Player

Collaborative eSport Whiteboard

Instant Messenger

Real Time Live Stream Player

Collaborative Communication

Collaborative and Synchronous Annotation & Discussion

5757

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 PDA’s• Integration with Web Service Containers and Handlers• Message and Stream Management Service• Dynamic meta-data services for “sessions”

DoD NCOW Comparison with OGSA

5858

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

5959

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