11

Grids for DoD andReal Time SimulationsIEEE DS-RT 2005 Montreal Canada Oct. 11 2005

Geoffrey Fox

Computer Science, Informatics, Physics

Pervasive Technology Laboratories

Indiana University Bloomington IN 47401

gcf@indiana.edu

http://www.infomall.org

22

Why are Grids Important 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

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

DoD and Distributed Simulation communities are too small to go it alone – they need to use technology that industry will support and enhance

33

Internet Scale Distributed Services 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

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 Organization can be implicit as in Internet resources such as

curated databases and simulation resources that “harmonize a community”

44

Different Visions of the Grid Grid just refers to the technologies

• Or Grids represent the full system/Applications 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)

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

e-Science or Cyberinfrastructure are virtual organization Grids supporting global distributed science (note sensors, instruments are people are all distributed

Skype (Kazaa) VOIP system is a Peer-to-peer Grid (and VRVS/GlobalMMCS like Internet A/V conferencing are Collaboration Grids)

Commercial 3G Cell-phones and DoD ad-hoc network initiative are forming mobile Grids

55

Types of Computing Grids Running “Pleasing Parallel Jobs” as in United Devices, Entropia

(Desktop Grid) “cycle stealing systems” Can be managed (“inside” the enterprise as in Condor) or more

informal (as in SETI@Home) Computing-on-demand in Industry where jobs spawned are

perhaps very large (SAP, Oracle …) Support distributed file systems as in Legion (Avaki), Globus with

(web-enhanced) UNIX programming paradigm• Particle Physics will run some 30,000 simultaneous jobs

Distributed Simulation HLA/RTI style Grids Linking Supercomputers as in TeraGrid Pipelined applications linking data/instruments, compute,

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

multiple resources with a common interfaces Parallel Computing typically NOT suited for a Grid (latency)

6

Large Scale Parallel Computers

Old Style Metacomputing GridQuickTime™ and a

decompressorare needed to see this picture.

QuickTime™ and a decompressor

are needed to see this picture.

IMAGING INSTRUMENTS

COMPUTATIONALRESOURCES

LARGE-SCALE DATABASES

DATA ACQUISITION ,ANALYSIS

ADVANCEDVISUALIZATION

Analysis and Visualization

Spread a single large Problem over multiple supercomputers

Large Disks

77

Utility and Service Computing An important business application of Grids is believed to be

utility computing Namely support a pool of computers to be assigned as needed to

take-up extra demand• Pool shared between multiple applications

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

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

88

Simulation and the Grid 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 The workflow is designed to supported the integration of

distributed entities• Simulations (maybe parallel) and Filters

for example GCF General Coupling Framework from Manchester

• Databases and Sensors• Visualization and user interfaces

RTI should be built on workflow and inherit WS-*/GS-* and NCOW CES built on same

9

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 databases

• The Grid is built by coordinating such services assuming we have solved problem of programming the service

Service Data

1010

Two-level Programming II The Grid is discussing the composition of distributed

services with the runtime interfaces to Grid as opposed to UNIX pipes/data streams

Familiar from use of UNIX Shell, PERL or Python scripts to produce real applications from core programs

Such interpretative environments are the single processor analog of Grid Programming

Some projects like GrADS from Rice University are looking at integration between service and composition levels but dominant effort looks at each level separately

Service1 Service2

Service3 Service4

1111

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 either?• 4) 10 to 1000 ms – Internet delay: Workflow

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

ClassicProgramming

12Computation

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

1313

Information/Knowledge Grids Distributed (10’s to 1000’s) of data sources (instruments,

file systems, curated databases …) Data Deluge: 1 (now) to 100’s petabytes/year (2012)

• Moore’s law for Sensors Possible filters assigned dynamically (on-demand)

• Run image processing algorithm on telescope image• Run Gene sequencing algorithm on compiled data

Needs decision support front end with “what-if” simulations

Metadata (provenance) critical to annotate data

Integrate across experiments as in multi-wavelength astronomy

Data Deluge comes from pixels/year available

1414

Data Deluged Science Now particle physics will get 100 petabytes from CERN using

around 30,000 CPU’s simultaneously 24X7 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

Weather, climate, solid earth (EarthScope) Bioinformatics curated databases (Biocomplexity only 1000’s of

data points at present) Virtual Observatory and SkyServer in Astronomy Environmental Sensor nets 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

Data assimilation was not central to HPCC DoE ASCI set up because didn’t want test data!

15

Virtual Observatory Astronomy GridIntegrate Experiments

Radio Far-Infrared Visible

Visible + X-ray

Dust Map

Galaxy Density Map

16

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

17

myGrid Project• Imminent

‘deluge’ of data• Highly

heterogeneous• Highly

complex and inter-related

• Convergence of data and literature archives

18

A B C

The Williams Workflows

A: Identification of overlapping sequenceB: Characterisation of nucleotide sequenceC: Characterisation of protein sequence

1919

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

2020

SERVOGrid Requirements Seamless Access to Data repositories and large scale

computers Integration of multiple data sources including sensors,

databases, file systems with analysis system• Including filtered OGSA-DAI (Grid database access)

Rich meta-data generation and access with SERVOGrid specific Schema extending openGIS (Geography as a Web service) standards and using Semantic Grid

Portals with component model for user interfaces and web control of all capabilities

Collaboration to support world-wide work Basic Grid tools: workflow and notification NOT metacomputing

2121

SERVOGrid Portal Screen SERVOGrid Portal Screen ShotsShots

2222

Portal ArchitecturePortal ArchitectureC

lient

s (P

ure

HT

ML,

Jav

a A

pple

t ..

)

Agg

rega

tion

and

Ren

derin

g

PortalInternalServices

Portlet Class

Portlet Class

Portlet Class

Portlet Class:WebForm

SERVOGrid(IU)

Web/Gridservice

Web/Gridservice

Web/Gridservice

Computing

Data Stores

Instruments

GridPortetc.

(Java)COG Kit

Clients Portal Portlets Libraries Services Resources

LocalPortlets

Remoteor ProxyPortlets

Hierarchical arrangement

OGCEOGCEConsortium

Individual portlet for the Proxy Manager

Use tabs or choose different portlets to navigate through interfaces to different services

2 Other Portlets

Each Servicehas its own portlet

2424

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

2525

A Screen Shot From the WMS Client

2626

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>

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

28

Typical use of Grid Messaging in NASA

Datamining Grid

Sensor Grid

Grid Eventing GIS Grid

29

Typical use of Grid Messaging

HPSearchManages

NaradaBrokering

Sensor Grid

WS-ContextStores dynamic data

Filter orDatamining

WFS (GIS data)

Post beforeProcessing

Post afterProcessing

Notify

SubscribeGrid DatabaseArchives

Web Feature Service

GIS Grid

GeographicalInformation System

30

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.

31

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

Integrating Archived Web

Feature Services and Google Maps

32

Google Maps as Service

accessed from our WMS

Client

3333

What is Happening? 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) Service Standards are being debated Grid Operational Infrastructure is being deployed Grid Architecture and core software being developed

• Apache has several important projects as do academia; large and small companies

Particular System Services are being developed “centrally” – OGSA or GS-* framework for this in GGF; WS-* for OASIS/W3C/Microsoft-IBM

Lots of fields are setting domain specific standards and building domain specific services

USA started but now Europe is probably in the lead and Asia will soon catch USA if momentum (roughly zero for USA) continues

34

The Grid and Web Service Institutional Hierarchy

1: Container and Run Time (Hosting) Environment

2: System Services and FeaturesHandlers like WS-RM, Security, Programming Models like BPEL

or Registries like UDDI

3: Generally Useful Services and FeaturesSuch as “Access a Database” or “Submit a Job” or “ManageCluster” or “Support a Portal” or “Collaborative Visualization”

4: Application or Community of InterestSpecific Services

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

OGSA GS-*and some WS-*GGF/W3C/….

WS-* fromOASIS/W3C/Industry

Apache Axis.NET etc.

Must set standards to get interoperability

3535

Philosophy of Web Service Grids Much of Distributed Computing was built by natural

extensions of computing models developed for sequential machines

This leads to the distributed object (DO) model represented by Java and CORBA• RPC (Remote Procedure Call) or RMI (Remote Method

Invocation) for Java 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

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

Thus replace distributed objects by services connected by “one-way” messages and not by request-response messages

36

The Ten areas covered by the 60 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)

RTI and NCOW needs all of these?

3737

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

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 information for Grid application service

3939

WS-I InteroperabilityWS-I Interoperability Critical underpinning of Grids and Web Services is Critical underpinning of Grids and Web Services is

the gradually growing set of specifications in the the gradually growing set of specifications in the Web Service Interoperability ProfilesWeb Service Interoperability Profiles

Web Services InteroperabilityWeb Services Interoperability (WS-I) Interoperability (WS-I) Interoperability Profile 1.0a." Profile 1.0a." http://www.ws-i.orghttp://www.ws-i.org. gives us . gives us XSD, XSD, WSDL1.1, SOAP1.1, UDDIWSDL1.1, SOAP1.1, UDDI in basic profile and parts in basic profile and parts of of WS-Security WS-Security in their first security profile.in their first security profile.

We imagine the “60 Specifications” being checked We imagine the “60 Specifications” being checked out and evolved in the out and evolved in the cauldron of the real worldcauldron of the real world and occasionally best practice identifies a new and occasionally best practice identifies a new specification to be added to specification to be added to WS-IWS-I which which gradually gradually increases in scopeincreases in scope• Note only 4.5 out of 60 specifications have Note only 4.5 out of 60 specifications have

“made it” in this definition“made it” in this definition

40

Activities in Global Grid Forum Working Groups

GGF Area GS-* and OGSA 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

RTI and NCOW needs all of these?

4141

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

4242

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

4343

High Performance Streams Optimize Stream representation and transport protocol

SOAP’’Filter2-1

StdSOAP Filter1 SOAP’ StdSOAPFilter1-1SOAP’

Database(WS-Context)

Choose InvertibleFilterPreservingInfoset

Choose Protocol

SOAP’’ Filter2

Coordinating betweenSource, Sink, SOAPIntermediaries andbetween different messages in a stream

Conversation Context

4444

High Performance XML 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

45

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.

4646

Major Conclusions I 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)

Some “mismatches” on both NCOW and Grid sides GS-*/WS-* do not have collaboration and miss some

messaging NCOW does not have at core level system metadata

and resource/service scheduling and matching Higher level services of importance include GIS

(Geographical Information Systems), Sensors and data-mining

4747

Major Conclusions II Criticisms of Web services in a recent paper by

Birman seem to be addressed by Grids or reflect immaturity of initial technology implementations

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 Grid of Grids allows modular architectures and

natural treatment of legacy systems

48

DoD Core Services and WS-* plus GS-* 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

49

DoD Core Services: WS-* and GS-* 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

5050

Grids and HLA/RTI I HLA through IEEE1516 has specified the interfaces for its key

services that are supported by RTI (Run Time Infrastructure) 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

Grids can be used in an “unchanged” HLA with• Dynamic assignment of compute resources to support federates

• Building web service interfaces to federates (XMSF) Or use Grids as Infrastructure to build a new generation of RTI

that will use Web system services and just add simulation support

5151

Grids and HLA/RTI II 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)

5252

GlobalMMCS Web Service Architecture

SIP H323 Access Grid Native XGSPAdmire

Gateways convert to uniform XGSP Messaging

High Performance (RTP)and XML/SOAP and ..

Media ServersFilters

Session ServerXGSP-based Control

NaradaBrokeringAll Messaging

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

NB Scales asdistributed

WebServices

NaradaBrokering

5353

GlobalMMCS Architecture

Event Messaging Service

(NaradaBrokering)

XGSP Conference Control Service

Audio Video

Web Service

Instant Messaging

Web Service

Shared Display

Web Service

Shared

….

Web Service

Non-WS collaboration control protocols are “gatewayed” to XGSP

NaradaBrokering supports TCP (chat, control, shared display, PowerPoint etc.) and UDP (Audio-Video conferencing)

5454

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>

5555

XGSP AV Signaling Protocol with H.323H323 Terminal H323 Gateway

H225.Setup

H225.Connect

JoinAVSession

JoinAVSession OK

Terminal CapabilitySet

ACK

Terminal Capability Set

ACK

OpenLogicChannel ( Video )

ACK

JoinAVSession (Video)ACK

OpenLogicChannel ( Video )

OpenLogicChannel ( Audio )

ACK

OpenLogicChannel ( Audio )

ACK JoinAVSession (Audio)

ACK with video RTPLink<IP Addr, Port>

ACK with Audio RTPLink<IP Addr, Port>

with the RTPLinks <IP Addr, Port>

& capability description

H.225Call Setup

H.245CapabilityExchange

OpenAudio &VideoLogicChannels

XGSP H323Session server

5656

NaradaBrokering 2003-2006 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)

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

Multicast, RTP SOAP message support and WS-Eventing, WS-RM and WS-Reliability.

• WS-Notification when specification agreed Active replay support: Pause and Replay live streams. Stream Linkage: can link permanently multiple streams – using in

annotation of 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 (?) High Performance Transport supporting SOAP Infoset

57

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

Latency ms

# Receivers

One sessionMultiple sessions

30 frames/sec

58

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

59GlobalMMCS SWT Client

Chat

TV

WebcamVideo Mixer

GIS

6060

e - Annotation Player

Archived stream player Annotation / WB

player

Archieved stream list

Real time stream list

e - Annotation Whiteboard

Real time stream player Archived Real Time Real Time

Stream List Stream List Player

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

6161

Some ideas to Remember Grids replace previous sophisticated distributed object

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

Grids are managed Services exchanging Messages Grid Services GS-* extend WS-* Web Service Specifications Web Service container replaces computer Service replaces process A stream is an ordered set of messages Service Internet replaces Internet: messages replace packets (Sub)Grids replace Libraries 7.5 out of 9 NCOW Core Enterprise Services CES directly from

Grid Services; metadata, (part of) messaging, collaboration, and sensors need special attention

RTI should be enhanced with agreed service interfaces and interoperable RTI-SOA

6262

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 (with POLIS center)

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