Grids for DoD and Real Time Simulations

Grids for DoD an

Real Time Simulations

IEEE DS-RT 2005 Montreal Canada Oct. 11 2005

Geoffrey Fox

Computer Science, Informatics, Physics Pervasive Technology Laboratories Indiana University Bloomington IN 47401

[email protected]

Why are Grids Important

n

Grids are important for

DoD

because they more or less

directly

address DoD’s problem

and have made

major

progress in the core infrastructure

that DoD has

identified rather qualitatively

n

Grids are important to

distributed simulation

because

they address

all the distributed systems issues except

simulation

and in any sophisticated distributed

simulation package,

most of the software

is not to do

with simulation but rather the

issues Grids address

n

DoD

and

Distributed Simulation

communities are

too

small

to go it alone – they need to

use technology that

industry will support

and enhance

Internet Scale Distributed Services

n Grids use Internet technology and are distinguished by

managing or organizing sets of network connected resources

• Classic Web allows independent one-to-one access to

individual resources

• Grids integrate together and manage multiple

Internet-connected resources: People, Sensors, computers, data

systems

n Organization can be explicit as in

• TeraGrid which federates many supercomputers;

• Deep Web Technologies IR Grid which federates multiple

data resources;

• CrisisGrid which federates first responders, commanders,

sensors, GIS, (Tsunami) simulations, science/public data

n Organization can be implicit as in Internet resources such as

curated databases and simulation resources that “harmonize a community”

Different Visions of the Grid

n Grid just refers to the technologies

• Or Grids represent the full system/Applications

n DoD’s vision of Network Centric Computing can be considered a

Grid (linking sensors, warfighters, commanders, backend

resources) and they are building the GiG (Global Information

Grid)

n Utility Computing or X-on-demand (X=data, computer ..) is

major computer Industry interest in Grids and this is key part of

enterprise or campus Grids

n e-Science or Cyberinfrastructure are virtual organization Grids

supporting global distributed science (note sensors, instruments are people are all distributed

n Skype (Kazaa) VOIP system is a Peer-to-peer Grid (and

VRVS/GlobalMMCS like Internet A/V conferencing are

Collaboration Grids)

n Commercial 3G Cell-phones and DoD ad-hoc network initiative

are forming mobile Grids

Types of Computing Grids

n Running “Pleasing Parallel Jobs” as in United Devices, Entropia

(Desktop Grid) “cycle stealing systems”

n Can be managed (“inside” the enterprise as in Condor) or more

informal (as in SETI@Home)

n Computing-on-demand in Industry where jobs spawned are

perhaps very large (SAP, Oracle …)

n Support distributed file systems as in Legion (Avaki), Globus with

(web-enhanced) UNIX programming paradigm

• Particle Physics will run some 30,000 simultaneous jobs

n Distributed Simulation HLA/RTI style Grids

n Linking Supercomputers as in TeraGrid

n Pipelined applications linking data/instruments, compute,

visualization

n Seamless Access where Grid portals allow one to choose one of

multiple resources with a common interfaces

n Parallel Computing typically NOT suited for a Grid (latency)

Large Scale Parallel Computers

Old Style Metacomputing Grid

Analysis and Visualization

Spread a single large Problem over multiple supercomputers

Large Disks

Utility and Service Computing

n An important business application of Grids is believed to be

utility computing

n Namely support a pool of computers to be assigned as needed to

take-up extra demand

• Pool shared between multiple applications

n Natural architecture is not a cluster of computers connected to

each other but rather a “Farm of Grid Services” connected to Internet and supporting services such as

• Web Servers

• Financial Modeling

• Run SAP

• Data-mining

• Simulation response to crisis like forest fire or earthquake

• Media Servers for Video-over-IP

n Note classic Supercomputer use is to allow full access to do

“anything” via ssh etc.

• In service model, one pre-configures services for all programs

and you access portal to run job with less security issues

Simulation and the Grid

n

Simulation on the Grid

is

distributed

but its

rarely classical

distributed simulation

•

It is either managing multiple jobs that are identical

except for parameters controlling simulation –

SETI@Home style of “

desktop grid

”

•

Or workflow that roughly corresponds to federation

n

The

workflow

is designed to supported the integration of

distributed entities

•

Simulations (maybe parallel) and Filter

for example

GCF

General Coupling Framework from

Manchester

•

Databases and Sensors

•

Visualization and user interfaces

n

RTI

should be built on

workflow

and inherit

WS-*/GS-*

and

NCOW CES

built on same

Two-level Programming I

• The Web Service (Grid) paradigm implicitly assumes a

two-level Programming Model

• We make a

Service

(same as a “distributed object” or

“computer program” running on a remote computer) using

conventional technologies

– C++ Java or Fortran Monte Carlo module – Data streaming from a sensor or Satellite – Specialized (JDBC) database access

• Such

services

accept and produce data from users files and

database

• The Grid is built by coordinating such services assuming

we have solved problem of programming the service

Servic

e Data

Two-level Programming II

n

The Grid is discussing the composition of distributed

services

with the runtime

interfaces to Grid as

opposed to UNIX

pipes/data streams

n

Familiar from use of UNIX Shell, PERL or Python

scripts to produce real applications from core programs

n

Such interpretative environments are the single

processor analog of

Grid Programming

n

Some projects like GrADS from Rice University are

looking at integration between service and composition

levels but dominant effort looks at each level separately

Service

1 Service2

Service

3 Service4

Consequences of Rule of the Millisecond

n

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

• 4) 10 to 1000 ms – Internet delay: Workflow

n

2a), 4) implies geographically distributed

metacomputing

can’t in general compete with parallel

systems

n

3) << 4) implies a software overlay network is possible

without significant overhead

• We need to explain why it adds value of course!

n

2b) versus 3) and 4) describes regions where

method

and

message

based programming paradigms important

Classic

Programming

Computation

Starlight (Chicago)

Netherlight (Amsterdam)

Leeds

PSC SDSC

UCL

Network PoP Service Registry

NCSA

Manchester

UKLight Oxford

RAL

US TeraGrid

UK NGS

Steering clients

SC05

Local laptops in Seattle and UK All sites connected by

production network (not all shown)

Towards an

International Grid

Infrastructure

Information/Knowledge Grids

n

Distributed

(10’s to 1000’s) of

data sources

(instruments,

file systems, curated databases …)

n

Data Deluge

: 1 (now) to 100’s

petabyte

s/year (2012)

• Moore’s law for Sensors

n

Possible

filters

assigned dynamically (

on-demand

)

•

Run image processing algorithm on telescope image

Run Gene sequencing algorithm on compiled data

n

Needs

decision support

front end with “what-if”

simulations

n

Metadata

(

provenance

)

critical to annotate data

n

Integrate

across experiment

as in multi-wavelength

astronomy

Data Deluged Science

n Now particle physics will get 100 petabytes from CERN using

around 30,000 CPU’s simultaneously 24X7

n Exponential growth in data and compare to:

• The Bible = 5 Megabytes

• Annual refereed papers = 1 Terabyte

• Library of Congress = 20 Terabytes

• Internet Archive (1996 – 2002) = 100 Terabytes

n Weather, climate, solid earth (EarthScope)

n Bioinformatics curated databases (Biocomplexity only 1000’s of

data points at present)

n Virtual Observatory and SkyServer in Astronomy

n Environmental Sensor nets

n In the past, HPCC community worried about data in the form of

parallel I/O or MPI-IO, but we didn’t consider it as an enabler of new science and new ways of computing

n Data assimilation was not central to HPCC

n DoE ASCI set up because didn’t want test data!

Virtual Observatory Astronomy Gri

Integrate Experiments

Radio Far-Infrared Visible

Visible + X-ray

Dust Map

Galaxy Density Map

International Virtual

Observatory Alliance

• Reached international agreements on

Astronomical Data Query Language, VOTable

1.1, UCD 1+, Resource Metadata Schema

• Image Access Protocol, Spectral Access

Protocol and Spectral Data Model, Space-Time

Coordinates definitions and schema

• Interoperable registries by Jan 2005 (NVO,

AstroGrid, AVO, JVO) using OAI publishing and

harvesting

• So each Community of Interest builds data

AND service standards that build on GS-* and

myGrid Project

• Imminent

‘deluge’ of

data

• Highly

heterogeneous

• Highly

complex and

inter-related

• Convergence

of data and

literature

archives

A B C

The Williams

Workflows

A: Identification of

overlapping sequence

B: Characterisation of nucleotide sequence

C: Characterisation of

Database Database Analysis and Visualizatio Portal Repositorie Federated Databases Data Filte Services

Field Trip Data

Streaming Data Sensor s

?

Grid of Grids: Research Grid and Education Grid

SERVOGrid Requirements

n

Seamless Access

to Data repositories and large scale

computers

n

Integration

of

multiple data sources

including sensors,

databases, file systems with analysis system

• Including filtered OGSA-DAI (Grid database access)

n

Rich meta-data

generation and access with

SERVOGrid specific Schema

extending openGIS

(Geography as a Web service) standards and using

Semantic Grid

n

Portals

with component model for user interfaces and

web control of all capabilities

n

Collaboration

to support world-wide work

n

Basic Grid tools:

workflow

and

notification

n

NOT metacomputing

SERVOGrid Portal Screen

Shots

Portal Architecture

WebForm SERVOGrid(IU) Web/Griservice

Web/Gri service Web/Gri service Computing Data Stores Instruments GridPort etc. (Java) COG Kit

OGCE

Consortiu m

Individual portlet for the Proxy Manager

Use tabs or choose

different portlets to navigate through

interfaces to different

services

2 Other Portlets

GIS Grids and Sensor Grids

n

OGC

has defined a suite of

data structures

and

services

to support

Geographical Information Systems and

Sensors

n

GML

Geography Markup language defines

specification of geo-referenced data

n

SensorML

and

O&M

(Observation and Measurements)

define meta-data and data structure for sensors

n

Services like

Web Map Service, Web Feature Service,

Sensor Collection Service

define services interfaces to

access GIS and sensor information

n

Grid workflow

links services that are designed to

support streaming input and output messages

n

We are building Grid (Web) service implementations of

these specifications for NASA’s

SERVOGrid

A Screen Shot From the WMS Client

WMS uses WFS that uses data sources

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

Electric Power and Natural Gas data from LANL

Interdependent Critical Infrastructure Simulations

Zoom-in

Zoom-out

FeatureInfo mode

Measure distance mode

Clear Distance

Drag and Drop mode

Refresh to initial map

Typical use of Grid Messaging in NASA

Datamining Grid

Sensor Grid

Grid Eventing GIS Grid

Typical use of Grid Messaging

HPSearc h

Manages

Narad Brokering Sensor Grid

WS-Context

Stores dynamic data

Filter or Dataminin

g

WFS (GIS data)

Post befor Processing

Post afte Processing

Notify

Subscribe

Grid Database

Archives

Web Feature Service

GIS Grid

Geographica

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.

Google maps can be

integrated with Web Feature Service

Archives to filter and

browse seismic records.

Integrating

Archived Web

Feature Services

Google Maps

as Service

accessed from

our WMS

What is Happening?

n Grid ideas are being developed in (at least) four communities

• Web Service – W3C, OASIS, (DMTF)

• Grid Forum (High Performance Computing, e-Science)

• Enterprise Grid Alliance (Commercial “Grid Forum” with a

near term focus)

n Service Standards are being debated

n Grid Operational Infrastructure is being deployed

n Grid Architecture and core software being developed

• Apache has several important projects as do academia; large

and small companies

n Particular System Services are being developed “centrally” –

OGSA or GS-* framework for this in GGF; WS-* for

OASIS/W3C/Microsoft-IBM

n Lots of fields are setting domain specific standards and building

domain specific services

n USA started but now Europe is probably in the lead and Asia

will soon catch USA if momentum (roughly zero for USA) continues

The Grid and Web Service Institutional Hierarchy

1: Container an

Run Time (Hosting) Environment 2: System Services and Features

Handlers like WS-RM, Security, Programming Models like BPE or Registries like UDDI

3: Generally Useful Services and Features

Such as “Access a Database” or “Submit a Job” or “Manag Cluster” or “Support a Portal” or “Collaborative Visualization”

4: Application or Community of Interes Specific Services

such as “Run BLAST” or “Look at Houses for sale”

OGSA GS-*

and some WS-* GGF/W3C/…

WS-* fro OASIS/W3C Industry

Apache Axi .NET etc.

Philosophy of Web Service Grids

n

Much of Distributed Computing was built by natural

extensions of computing models developed for sequential

machines

n

This leads to the

distributed object

(DO) model represented

by Java and

CORBA

•

RPC (Remote Procedure Call) or RMI (Remote Method

Invocation) for Java

n

Key people think this is not a good idea as it scales badly

and ties distributed entities together too tightly

•

Distributed Objects

Replaced by

Services

n

Note

CORBA

was considered too complicated in both

organization and proposed infrastructure

•

and

Java

was considered as “tightly coupled to Sun”

So there were other reasons to discard

n

Thus replace distributed objects by

services

connected by

“

one-way

” messages and not by request-response messages

The Ten areas covered by the 60 core WS-* Specifications

WSRP (Remote Portlets) 10: Portals and User Interfaces

WS-Policy, WS-Agreement 9: Policy and Agreements

WSDM, WS-Management, WS-Transfer 8: Management

WSRF, WS-MetadataExchange, WS-Context 7: System Metadata and State

UDDI, WS-Discovery 6: Service Discovery

WS-Security, WS-Trust, WS-Federation, SAML, WS-SecureConversation

5: Security

BPEL, WS-Choreography, WS-Coordination 4: Workflow and Transactions

WS-Notification, WS-Eventing (Publish-Subscribe) 3: Notification

WS-Addressing, WS-MessageDelivery; Reliable Messaging WSRM; Efficient Messaging MOTM 2: Service Internet

XML, WSDL, SOAP 1: Core Service Model

Examples WS-* Specification Area

RTI and NCOW needs all of

Stateful Interactions

n

There are (at least) four approaches to specifying state

•

OGSI

use factories to generate separate services for

each session in standard distributed object fashion

•

Globus GT-4

and

WSRF

use metadata of a resource

to identify state associated with particular session

•

WS-GAF

uses

WS-Context

to provide abstract

context defining state. Has strength and weakness

that reveals less about nature of session

•

WS-I+

“Pure Web Service” leaves state specification

the application – e.g. put a context in the SOAP body

n

I think we should smile and write a great metadata

service hiding all these different models for state and

metadata

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

WS-I Interoperability

n

Critical underpinning of Grids and Web Services is the

gradually growing set of specifications in the Web Service

Interoperability Profiles

n

Web Services Interoperability

(WS-I) Interoperability

Profile 1.0a." h

ttp://www.ws-i.org.

gives us

XSD, WSDL1.1,

SOAP1.1, UDDI

in basic profile and parts of

WS-Security

in their first security profile.

n

We imagine the “60 Specifications” being checked out and

evolved in the

cauldron of the real world

and occasionally

best practice identifies a new specification to be added to

WS-I

which

gradually increases in scope

•

Note only 4.5 out of 60 specifications have “made

it” in this definition

Activities in Global Grid Forum Working Groups

Authorization, P2P and Firewall Issues, Trusted Computing 7: Security

Resource/Service configuration, deployment and lifetime, Usage records and access, Grid economy model

6: Management

Network measurements, Role of IPv6 and high performance networking, Data transport

5: Infrastructure

Database and File Grid access, Grid FTP, Storage Management, Data replication, Binary data specification and interface, High-level publish/subscribe, Transaction management

4: Data

Job Submission, Basic Execution Services, Service Level Agreements for Resource use and reservation, Distributed Scheduling

3: Compute

Software Interfaces to Grid, Grid Remote Procedure Call, Checkpointing and Recovery, Interoperability to Job Submittal services, Information Retrieval,

2: Applications

High Level Resource/Service Naming (level 2 of fig. 1), Integrated Grid Architecture

1: Architecture

GS-* and OGSA Standards Activities GGF Area

RTI and NCOW needs all of

SOAP Message Structure I

n SOAP Message consists of headers and a body

• Headers could be for Addressing, WSRM, Security, Eventing etc.

n Headers are processed by handlers or filters controlled by

container as message enters or leaves a service

n Body processed by Service itself

n The header processing defines the “Web Service Distributed

Operating System”

n Containers queue messages; control processing of headers and

offer convenient (for particular languages) service interfaces

n 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 H2 H3 H4 Body F₁ F₂ F₃ F₄ Servic_e Container Handlers

Container Workflow

SOAP Message Structure II

n Content of individual headers and the body is defined by XML

Schema associated with WS-* headers and the service WSDL

n SOAP Infoset captures header and body structure

n XML Infoset for individual headers and the body capture the

details of each message part

n 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 H2 H3 H4 _Body

bp1 bp2 bp3 hp1 hp2 hp3 hp4 hp5

Infoset represent semantic structure of message and it parts

High Performance Streams

n

Optimize Stream representation and transport protocol

SOAP’’ Filter2

-1

StdSOAP Filter₁ SOAP’ SOAP’ Filter11 - StdSOAP

Databas (WS-Context)

Choose Invertible Filter

Preservin Infoset

Choose Protocol

SOAP’’ Filter₂

Coordinating between Source, Sink, SOAP Intermediaries an between different

messages in a stream

High Performance XML

n Filters controlled by Conversation Context convert messages

between representations using permanent context (metadata) catalog to hold conversation context

n 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

n NaradaBrokering will implement Fr and Ft using its support of

multiple transports, fast filters and message queuing;

H1 H2 H3 H4 Body

Servic e

Conversation Contex URI-S, URI-R, URI-T Replicated Message

Header

Transported Message _Handler

Message View _{Message View}Servic

Container Handlers Ft Fr F₃ F₄

The Global Information Grid Core Enterprise Services

Provisioning, operations and maintenance of applications. CES9: Application

Retention, organization and disposition of all forms of data

CES8: Storage

Includes automated and manual methods of optimizing the user GiG experience (user agent)

CES7: User Assistance

Provision and control of sharing with emphasis on synchronous real-time services

CES6: Collaboration

Includes translation, aggregation, integration, correlation, fusion, brokering publication, and other transformations for services and data. Possibly agents

CES5: Mediation

Searching data and services CES4: Discovery

Synchronous or asynchronous cases CES3: Messaging

Supports confidentiality, integrity and availability. Implies reliability and autonomic features

CES2: Information

Assurance (IA)/Security

including life-cycle management CES1: Enterprise Services

Management (ESM)

Service Functionality Core Enterprise Services

Major Conclusions I

n

One can map

7.5 out of 9

NCOW and GiG core

capabilities into Web Service (WS-*) and Grid (GS-*)

architecture and core services

•

Analysis of Grids in NCOW document inaccurate

(confuse Grids and Globus and only consider early

activities)

n

Some “mismatches” on both NCOW and Grid sides

n

GS-*/WS-*

do

not

have

collaboration

and miss some

messaging

n

NCOW does not have at core level

system metadata

and

resource/service scheduling

and matching

n

Higher level services

of importance include

GIS

(Geographical Information Systems),

Sensors

and

data-mining

Major Conclusions II

n

Criticisms

of Web services in a recent paper by

Birman seem to be

addressed by Grids

or reflect

immaturity of initial technology implementations

n

NCOW does not seem to have any analysis of how to

build their systems on

WS-*/GS-*

technologies in a

layered fashion; they do have a layered service

architecture so this can be done

•

They agree with

service oriented architecture

•

They seem to have

no process

for agreeing to WS-*

GS-* or setting other standards for CES

n

Grid of Grids

allows modular architectures and

natural treatment of legacy systems

DoD Core Services and WS-* plus GS-* I

Portlets, JSR16 NCOW Capability Interfaces

WS- * #10

CES 7: User assistance

XGSP, Shared Web Service ports

GGF VO. VO

CES 6: Collaboration

Treatment of Legacy systems. Data Transformations

WS-* #4 workflow

CES 5: Mediation

WS-* #6

CES 4: Discovery

JMS, MQSeries,Streaming /Sensor Technologies WS-* #2, #3

CES 3: Messaging

Grid-Shib, Permis Liberty Alliance etc.

GGF #7, WS-* #5

WS-Security

CES 2: Information Assurance(IA)/Security

CIM GGF #6: Management

WS-* #8 Management

CES 1: Enterprise Services Management

B: NCOW Core Services (to be continued)

Strategy for legacy subsystems and modular architecture

Grid of Grids Composition

Industry Best Practice (IBM, Microsoft …)

Build Grids on Web Services

Core Service Model (#1)

Use Service Oriented Architecture

A: General Principles

Others GGF

WS-* Service area NCOW Service or Feature

DoD Core Services: WS-* and GS-* II

OGC GIS standards

GIS

OGC Sensor standards

Sensors (real-time data)

Extend computer scheduling to networks and data flow

GGF scheduling work extended to networks Distributed

Scheduling and SLA’s (GGF # 3)

Resource/Service Matching/Scheduling Semantic Web; Annotation Semantic Grid Globus MDS WS-* #7 Meta-data

C: Key NCOW Capabilities not directly in CES

giG itself; Ad-hoc networks important GGF #5; Resource Infrastructure WS-*, #9 Environmental Control Services ECS

Best Practice in building Grid/Web services

GGF #2

CES 9: Application

NCOW Data Strategy GGF #4 Data

CES 8: Storage (not real-time streams)

B: NCOW Core Services Continued

Others GGF

WS-* Service area NCOW Service or Feature

Grids and HLA/RTI I

n HLA through IEEE1516 has specified the interfaces for its key

services that are supported by RTI (Run Time Infrastructure)

n HLA does not specify each message semantics or core system

services

• RTI implementations are NOT interoperable although each

one should support any HLA federation

• RTI implementations become a full distributed system

environment as need metadata, reliable messaging etc. with simulation support only a small part

n

Grids can be used

in an “

unchanged

” HLA with

• Dynamic assignment of compute resources to support

federates

• Building web service interfaces to federates (XMSF)

n Or use Grids as Infrastructure to build a new generation of RTI

that will use Web system services and just add simulation support

Grids and HLA/RTI II

n HLA specifies

• Declaration management – achieved through use of

publish/subscribe Grid Messaging (NaradaBrokering)

• Data Distribution management – corresponds to geometry

sensitive publish and subscribe model (add as allowed in WS-Eventing)

• Time management – corresponds to simulation framework

(use best event driven and time stepped models – as

infrastructure generic, one can support broad range of

simulations including classic parallel computing and agent-based simulations)

• Object management - Very specific to HLA and should be built

as per IEEE1516

• Ownership management - could use Grid virtualization and

use metadata catalog catalogs to handle properties – might be generalizable

• Federation management - Could use workflow and generalize

to support of general simulation models (federates and federations are a general concept)

GlobalMMCS Web Service Architecture

SIP H323 Access_Grid Native_XGSP Admire

Gateways convert to uniform XGSP Messaging

High Performance (RTP and XML/SOAP and ..

Media Servers

Filters Session Server

XGSP-based Control

NaradaBrokerin g

All Messaging

Use Multiple Media servers to scale to many codecs and many versions of audio/video mixing

NB Scales a distributed

We Services

NaradaBrokering

GlobalMMCS Architecture

Event Messaging Service

(NaradaBrokering)

XGSP Conference Control Service

Audio Video

Web Service MessagingInstant Web Service

Shared Display Web Service

Shared ….

Web Service

n

Non-WS collaboration

control protocols are

“gatewayed” to XGSP

n

NaradaBrokering

supports TCP (chat, control, shared

display, PowerPoint etc.) and UDP (Audio-Video

conferencing)

XGSP Example: New Session

<CreateAppSession>

<ConferenceID> GameRoom </ConferenceID> <ApplicationID> chess </ApplicationID>

<AppSessionID> chess-0 </AppSessionID>

<AppSession-Creator> John </AppSession-Creator> <Private> false </Private>

</CreateAppSession> <SetAppRole>

<AppSessionID> chess-0 </AppSessionID> <UserID> Bob </UserID>

<RoleDescription> black </RoleDescription> </SetAppRole>

<SetAppRole>

<AppSessionID> chess-0 </AppSessionID> <UserID> Jack </UserID>

<RoleDescription> white </RoleDescription> </SetAppRole>

XGSP AV Signaling Protocol with H.323

H323 Terminal _{H323 Gatewa}

y H225.Setup H225.Connect JoinAVSessio n JoinAVSession OK Terminal Capability Se t AC K

Terminal Capability Set AC

K

OpenLogicChannel ( Video ) AC K JoinAVSessio n (Video) AC K

OpenLogicChannel ( Video )

OpenLogicChannel ( Audio ) AC

K

OpenLogicChannel ( Audio ) AC

K JoinAVSessio_n (Audio)

ACK with video RTPLink <IP Addr, Port>

ACK with Audio

RTPLink<IP Addr, Port>

with the RTPLinks <IP Addr, Port>

& capability description

NaradaBrokering 2003-2006

n Messaging infrastructure for collaboration, peer-to-peer and Grids

Implements JMS and native high-performance protocols (message transit time of 1 to 2 ms per hop)

n Order-preserving message transport with QoS and security profiles n Support for different underlying transport such as TCP, UDP,

Multicast, RTP

n SOAP message support and WS-Eventing, WS-RM and WS-Reliability.

• WS-Notification when specification agreed

n Active replay support: Pause and Replay live streams.

n Stream Linkage: can link permanently multiple streams – using in

annotation of real-time video streams

n Replicated storage support for fault tolerance and resiliency to storage

failures.

n Management: HPSearch Scripting Interface to streams and brokers

(uses WS-Management)

n Broker Topics and Message Discovery: Locate appropriate

n Integration with Axis2 Web Service Container (?)

n High Performance Transport supporting SOAP Infoset

Average Video Delays for one broker –

Performance scales proportional to number of brokers

Latency ms

# Receivers One session Multipl

sessions

30 frames/sec

GlobalMMCS SWT Client

Chat TV

Webcam Video

Mixer GIS

e - Annotation Playe

r

Archived stream playe

r

Annotatio

nplaye / WB r

Archieved stream

list

Real time stream

list

e -Annotation Whiteboar

d

Real time stream playe

r

Archived Real Time Real Tim Stream List Stream List Player

e-Annotation Archived Stream Annotated e-Annotation Player Player Stream Player Whiteboard

Some ideas to Remember

technologies because industry won’t support DO’s but will support services

n Grids are managed Services exchanging Messages

n Grid Services GS-* extend WS-* Web Service Specifications n Web Service container replaces computer

n Service replaces process

n A stream is an ordered set of messages

n Service Internet replaces Internet: messages replace packets

n (Sub)Grids replace Libraries

n 7.5 out of 9 NCOW Core Enterprise Services CES directly from

Grid Services; metadata, (part of) messaging, collaboration, and

sensors need special attention

n RTI should be enhanced with agreed service interfaces and

interoperable RTI-SOA

Location of software for Grid Projects in

Community Grids Laboratory

n

htpp://www.naradabrokering.org p

rovides Web service

(and JMS) compliant

distributed publish-subscribe

messaging

(software overlay network)

n

h

tpp://www.globlmmcs.org is

a

service oriented (Grid)

collaboration environment

(audio-video conferencing)

n

ht

tp://www.crisisgrid.org is

an OGC (open geospatial

consortium) Geographical Information System (GIS)

compliant

GIS and Sensor Grid

(with POLIS center)

n

htt

p://www.opengrids.org has

WS-Context, Extended

UDDI etc.

n

The work is still in progress but NaradaBrokering is

quite mature

n

All software is open source

and freely available