Transcript Essential Ideas    Distributed software systems are being “revolutionized” by developments from e-commerce, eScience and the consumer Internet.

Essential Ideas



Distributed software systems are being
“revolutionized” by developments from e-commerce, eScience and the consumer Internet. There is rapid
progress in technology families termed “Web services”,
“Grids” and “Web 2.0”
Many of these developments have important
implications for collaboration both in terms of core
technology and capabilities
The emerging picture is of distributed services with
advertised interfaces but opaque implementations
communicating by streams of messages over a variety
of protocols
• Complete systems are built by combining either services or
Grids (predefined/pre-existing collections of services) together
to achieve new capabilities
1

The Three Technology Families
Web Services have clearly defined protocols (SOAP) and a well
defined mechanism (WSDL) to define service interfaces
• There is good .NET and Java support
• The so-called WS-* specifications provide a rich sophisticated standard set
of capabilities for security, fault tolerance, meta-data, discovery,
notification etc.


Grids build on Web Services and provide a robust managed
environment with growing adoption in Enterprise systems and
distributed science (so called e-Science)
Web 2.0 supports a similar architecture to Web services but has
developed in a more chaotic but remarkably successful fashion
with a service architecture with a variety of protocols including
those of Web and Grid services
• Over 350 Interfaces defined at http://www.programmableweb.com/apis


Web 2.0 also has many well known capabilities with Google
Maps and Amazon Compute/Storage services of clear general
relevance to DoD
There are also Web 2.0 services supporting novel collaboration
modes as seen in social networking sites, portals, MySpace,
YouTube,
2
The three service technologies and DoD



The Web Service, Grid and Web 2.0 approaches differ in
important detail but their broad architectures are similar and so
it is possible to use them all in DoD applications
We expect growing support with rich functionality for all three
technology approaches and this plus the broad interoperability
enabled by a service architecture, has important implications for
capabilities and ease of maintenance and upgrade for DoD
systems built on these broad-based service technologies
Anabas analyzed in detail the Net Centric NCOW specifications
and showed how they could be mapped into Web and Grid
services
• This included the NCOW Core Enterprise Services and also Sensor Grids
and the NCOW Data Model
• Anabas also addressed how one could achieve managed consistent
architecture with the intrinsically distributed architecture
3



Anabas Approach
This is in collaboration with Community Grids Laboratory at
Indiana University
We follow the Grid architecture and use Web services for all
capabilities; if one needs a capability like Google Maps from
Web 2.0 it is wrapped as a Web Service (and in fact to use an
Open Geospatial Consortium Interface)
We use a powerful publish-subscribe messaging environment to
provide collaboration (via software overlay networks) and faulttolerance
• The same software is used to support both Web Service messaging (TCP)
and audio-video conferencing (UDP)



We package collections of services as Grids which provide
particular composite capability such as hosting a sensor Grid or
supporting one or more collaboration functions
We provide tools to build Grids by composing other Grids
together and to dynamically manage them
Anabas is subcontracting to Ball Aerospace to build
demonstration DoD relevant Grids
• Community Grids Laboratory will use technology for civilian critical
infrastructure especially for the Earthquake science and emergency
response areas
4
Comparison of Web 2.0
and Grids
See http://grids.ucs.indiana.edu/ptliupages/presentations/ogf19web20jan29-07.ppt
5
Architecture of
Streaming Grids of Grids
And describing the underlying messaging
system NaradaBrokering and how message
multicast enables collaboration
6
Raw Data 
S
S
S
S
FS
FS
FS
FS
MD
FS
MD
O
S
FS
O
S
FS
F
S
FS
MD
MD
SS
O
S
FS
FS
O
S
FS
MD
O
S
FS
F
S
O
S
MD
Filter Service
FS
O
S
FS
Other
Service
MD
O
S
FS
MetaData
SS
S
S
Database
O
S
FS
SS
Another
Grid
FS
O
S
O
S
SS
Decisions
MD
MD
FS
SS
FS
S
S
O
S
SS
Another
Service
 Wisdom
Knowledge
Another
Grid
FS
SS
Information 
S
S
Another
Grid
Data 
S
S
S
S
Another
Service
S
S
S
S
S
S
S
S
S
S
S
S
Sensor Service
7
Grid Service Philosophy I


Services receive data in SOAP messages, manipulate it
and produce transformed data as further messages
Knowledge is created from information by services
• Information is created from data by services




Semantic Grid comes from building metadata rich
systems of services
Meta-data is carried in SOAP messages
The Grid enhances Web services with semantically rich
system and application specific management
One must exploit and work around the different
approaches to meta-data (state) and their manipulation
in Web Services
8
Grid Service Philosophy II





There are a horde of support services supplying security,
collaboration, database access, user interfaces
The support services are either associated with system or
application where the former are WS-* and GS-* which
implicitly or explicitly define many support services
There are generalized filter services which are applications that
accept messages and produce new messages with some data
derived from that in input
• Simulations (including PDE’s and reactive systems)
• Data-mining
• Transformations
• Agents
• Reasoning
are all termed filters here
Agent Systems are a special case of Grids
Peer-to-peer systems can be built as a Grid with particular
discovery and messaging strategies
9
Grid Service Philosophy III







Filters can be a workflow which means they are “just
collections of other simpler services”
Grids are distributed systems that accept distributed
messages and produce distributed result messages
A service or a workflow is a special case of a Grid
A collection of services on a multi-core chip is a Grid
Sensors or Instruments are “managed” by services;
they may accept non SOAP control messages and
produce data as messages (that are not usually SOAP)
Collaborative services share either input (replicated
model) or output ports
Collaboration involves a sharing messaging system
(naturally publish-subscribe) and a control formalism
(XGSP is SOAP compatible H323/SIP)
10
Raw Data 
S
S
O
S
S
S
FS
FS
O
S
FS
SS
FS
FS
FS
FS
MD
FS
O
S
FS
FS
MD
MD
FS
O
S
MD
F
S
O
S
MD
F
S
FS
FS
O
FS S
Filter Service
FS
O
S
FS
Other
Service
MD
O
S
FS
MetaData
SS
S
S
Database
O
S
FS
SS
Another
Grid
FS
O
S
O
S
SS
Decisions
MD
MD
FS
SS
FS
S
S
O
S
SS
Another
Service
 Wisdom
Knowledge
Another
Grid
FS
SS
Information 
S
S
Another
Grid
Data 
S
S
S
S
Another
Service
S
S
S
S
S
S
S
S
S
S
Sensor Service
Collaboration11by
Message Replication
S
U
Web
F
Servic
I
I
e
O
O
F
S
U
Web
F
Servic
I
I
e
O
O
F
WS
Viewer
WS
Display
WS
Viewer
WS
Display
U
Web
F
Servic
I
I
e
O
O
F
Event
(Message)
Service
S
Master
Other
Participants
WS
Viewer
WS
Display
Shared Input Port (Replicated WS) Collaboration with UFIO
as User Facing and SFIO as Service Facing Ports
12
F
I
S
O
WSDL
Master
U
Application or
Content source
Web Service
O
F
I
Event
(Message)
Service
WS
Viewer
WS
Display
WS
Viewer
WS
Display
Other
Participants
WS
Viewer
Shared Output Port (Single WS) Collaboration that
Can be shared at any point on visualization pipeline
WS
Display
13
Raw Data 
O
S
O
S
S
S
S
S
FS
FS
FS
FS
MD
FS
MD
O
S
FS
O
S
FS
F
S
FS
MD
MD
SS
O
S
FS
FS
O
S
FS
FS
F
S
MD O
S
O
S
MD
Filter Service
FS
Other
Service
MD
O
S
FS
MetaData
SS
S
S
Database
FS
FS
SS
Decisions
MD
O
S
SS
Another
Grid
FS
MD
FS
SS
S
S
O
S
SS
Another
Service
 Wisdom
Knowledge
Another
Grid
FS
SS
Information 
S
S
Another
Grid
Data 
S
S
S
S
Another
Shared
Service
S
S
S
S
S
S
S
S
Display is the “last” filter
S
S
S
Sensor Service
Collaboration
by
S
Message Replication
at any point14in
filter chain
15
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.
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: Scripting Interface to streams and brokers (uses WSManagement) for initialization, firewall issues and fault tolerance
Broker Topics and Message Discovery: Locate appropriate
High Performance Transport supporting SOAP Infoset for GIS
applications
16
Standard Deviation (Milliseconds)
Round-trip delays for different payload sizes (100B - 10KB)
5
5
Delay
Standard Deviation
4 These measurements are messages from client to
4
broker and back using latest Java 1.6 release that
is about twice performance of earlier releases
3
3
2
2
1
0
100
1
1000
Content Payload Size (Bytes)
0
10000
17
60
50
40
30
Standard Deviation (Milliseconds)
Round-trip delays for different payload sizes (100B - 1MB)
20
Delay
70
Standard Deviation
18
These measurements are messages from client to
broker and back using latest Java 1.6 release that
is about twice performance of earlier releases.
This graph is identical to previous one for small
messages
20
10
0
100
16
14
12
10
8
6
4
2
1000
10000
100000
Content Payload Size (Bytes)
0
1e+006
18
Average Video Delays
UDP Performance when NaradaBrokering used
for audio-video conferencing
Latency ms
Multiple
sessions
One session
30 frames/sec
# Receivers
19
Analysis of DoD Net Centric
Services in terms of Web
and Grid services
20
The Grid and Web Service Institutional Hierarchy
4: Application or Community of Interest (CoI)
Specific Services such as “Map Services”, “Run
BLAST” or “Simulate a Missile”
XBML
XTCE VOTABLE
CML
CellML
3: Generally Useful Services and Features
(OGSA and other GGF, W3C) Such as “Collaborate”,
“Access a Database” or “Submit a Job”
OGSA GS-*
and some WS-*
GGF/W3C/….
XGSP (Collab)
2: System Services and Features
(WS-* from OASIS/W3C/Industry)
Handlers like WS-RM, Security, UDDI Registry
1: Container and Run Time (Hosting)
Environment (Apache Axis, .NET etc.)
Must set standards to get interoperability
WS-* from
OASIS/W3C/
Industry
Apache Axis
.NET etc.
21
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)
22
Activities in Global Grid Forum Working Groups
GGF Area
GS-* and OGSA Standards Activities
1: Architecture
High Level Resource/Service Naming (level 2 of slide 6),
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
23
Net-Centric Core Enterprise Services
Core Enterprise Services
Service Functionality
NCES1: Enterprise Services
Management (ESM)
including life-cycle management
NCES2: Information
Assurance (IA)/Security
Supports confidentiality, integrity and availability.
Implies reliability and autonomic features
NCES3: Messaging
Synchronous or asynchronous cases
NCES4: Discovery
Searching data and services
NCES5: Mediation
Includes
translation,
aggregation,
integration,
correlation, fusion, brokering publication, and other
transformations for services and data. Possibly agents
NCES6: Collaboration
Provision and control of sharing with emphasis on
synchronous real-time services
NCES7: User Assistance
Includes automated and manual methods of optimizing
the user GiG experience (user agent)
NCES8: Storage
Retention, organization and disposition of all forms of
data
NCES9: Application
Provisioning,
applications.
operations
and
maintenance
of
24
Produce the Needed Core Services
• We can classify services in many ways and
following 2 charts are one way; slightly changed
from proposal as NCOW and our work changed a
little.
• Green is “in hand”; we know a lot
• Orange is “in hand” with outside but available
solutions
• Red has problems – Security does not have
industry consensus while current Scheduling
work does not address DoD real-time service and
network requirements
25
The Core Features/Service Areas I
Service or Feature
WS-*
GS-*
NCES
(DoD)
Comments
A: Broad Principles
FS1: Use SOA: Service
Oriented Arch.
WS1
Core Service Architecture, Build Grids on Web
Services. Industry best practice
FS2: Grid of Grids
Distinctive Strategy for legacy subsystems and
modular architecture
B: Core Services
FS3: Service Internet,
Messaging
WS2
NCES3 Streams/Sensors. Team
FS4: Notification
WS3
NCES3 JMS, MQSeries.
FS5 Workflow
WS4
NCES5 Grid Programming
FS6 : Security
WS5
FS7: Discovery
WS6
FS8: System Metadata
& State
WS7
FS9: Management
WS8
FS10: Policy
WS9
GS7
NCES2 Grid-Shib, Permis Liberty Alliance ...
NCES4 UDDI
Globus MDS
Semantic Grid, WS-Context
GS6
NCES1 CIM
ECS
26
The Core Feature/Service Areas II
Service or Feature
WS-*
GS-*
NCES
Comments
NCES7
Portlets JSR168, NCES Capability Interfaces
NCES8
NCOW Data Strategy
Federation at data/information layer major
research area; CGL leading role
B: Core Services (Continued)
FS11: Portals and User WS10
assistance
FS12: Computing
GS3
FS13: Data and Storage
GS4
FS14: Information
GS4
FS15: Applications and User
Services
GS2
FS16: Resources and
Infrastructure
GS5
FS17: Collaboration and
Virtual Organizations
GS7
FS18: Scheduling and
matching of Services and
Resources
GS3
JBI for DoD, WFS for OGC
NCES9
Standalone Services
Proxies for jobs
Ad-hoc networks
NCES6
XGSP, Shared Web Service ports
Current work only addresses scheduling “batch
jobs”. Need networks and services
27
Some Conclusions I





One can map nearly all NCOW/NCES and GiG core
capabilities into Web Service (WS-*) and Grid (GS-*)
architecture and core services
• Analysis of Grids in NCOW/NCES 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
28
Some Conclusions II



Criticisms of Web services in a paper by Birman seem to
be addressed by Grids or reflect immaturity of initial
technology implementations
NCOW/NCES 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
• Note Grids, Services and Handlers are all “just”
entities with distributed message-based input and
output interfaces
29
Additional Services
• Sensors have low level support listed as FS3; higher
level integration using SensorML and Filters well
understood. Some work in phase I
• GIS Grid services pioneered by team and already
shown in phase I
• Mediation (Interoperability) Services needed to link
Grids (defined as a collection of ≥ 1 Services)
– Need to generalize existing solutions for Sensor Grids
and for MQSeries-SOAP Mediation
– View NaradaBrokering as a SOAP Intermediary
30
Out of Scope for Phase II
• Many areas are still evolving significantly
–
–
–
–
–
Mediation/Interoperation
Security
Scheduling of non-compute Resources
Data/Information Federation
Semantic Grid and management
• We will not test scalability on large number of
services, sensors and component Grids
• Integrating legacy systems not addressed
• Grid of Grids building tool is “new idea” – can
expect will benefit from further work
31
Grid of Grids
32
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 sharing common security, user
33
profile, file access .. services
•
•
•
•
•
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
Methods
CPUs
Services
Clusters
Component Grids
Compute
Resource Grids
MPPs
Databases
Sensor
Federated
Databases
Sensor Nets
Data
Resource Grids
Overlay
and Compose
Grids of Grids
34
Component Grids?


So we build collections of Web Services which we package as
component Grids
• Visualization Grid
• Sensor Grid
• Utility Computing Grid
• Collaboration Grid
• Earthquake Simulation Grid
• Control Room Grid
• Crisis Management Grid
• Drug Discovery Grid
• Bioinformatics Sequence Analysis Grid
• Intelligence Data-mining Grid
We build bigger Grids by composing component Grids using the
Service Internet
35
Using the Grid of Grids and Core Services to build multiple
application grids re-using common components.
BioInformatics Grid
Chemical Informatics Grid
15: Application Services
Services
Screening Tools
Quantum
Calculations
…
14: Information
11: Portals
17: Collaboration
9: Management
…
Domain Specific
Grids/Services
12: Computing
18: Scheduling
4: Notification
7: Discovery
6: Security
15: Application Services
Sequencing Tools
Biocomplexity
Simulations
Instrument/Sensor
13: Data Access/Storage
10: Policy
8:Metadata
Core Low Level Grid Services
3: Messaging
5: Workflow
9: Management
Physical Network (monitored by FS16)
36
Net Centric Grid
…
Electricity
CIGrid
…
Flood Services
and Filters
Military Services
and Filters
Collaboration Grid
Sensor Grid
Registry
Flood CIGrid
Portals
GIS Grid
Data Access/Storage
Information
Management Grid
Compute Grid
Metadata
Core Grid Services
Security
Notification
Workflow
Messaging
Physical Network
Net Centric and Critical Infrastructure (CI) Grids built as
Grids of Grids and re-using subGrids
37
Port
Mediation and Transformation in a
Grid of Grids and Simple Services
Port
Internal
Port
Interfaces
Port
Internal
Port
Port
Interfaces
Subgrid or service
Messaging
Port
Subgrid or service
Port
Internal
Port
Interfaces
Port
Port
Port
External facing
Interfaces
Mediation and
Transformation
Services
Subgrid or service
38
Grid of Grids Builder Tool
• This will provide a graphical interface to build grids
from existing libraries of Services and Grids
• Meta-data (provenance) needs to be specified
• Grids (services) need to be linked
• This will be built by extending an existing workflow
engine which is aimed at a more tightly couple
version of the builder problem
– We examined HPSearch (CGL), Taverna (Open source
from UK OMII), BPEL with user interface (OMII or IU
LEAD project), Eclipse
– Semantic Grid provenance “add-ons”
– We chose BPEL with an Eclipse interface
39
BPEL Workflow Designer
An example of GeoFest workflow
40
Setting the System Metadata and Policy



The Grid Builder will set up and launch a monitoring
framework that can provide fault tolerance for services and
message brokers
The properties set up at Grid definition stage are used to specify
initial set up of services and how they are to be restarted
This includes policy on what and how to restart
41
Technology Nuggets
produced for
Collaboration Grids
Group Support in Anabas Collaboration Framework
• Hybrid Shared Display
• GlobalMMCS is a collaboration system built using services
and publish-subscribe messaging
• Improved Java Media Framework
•
42
Collaborative Groups Illustrated
In Anabas Impromptu

Examples of applications:

private discussions in conference/lecture

simultaneous breakout groups

Multiple broadcasting in the same session (e.g.
audio/voice or video/TV channels for user-defined,
such as particular need-to-know, groups)
Group & Sharedlets



An Anabas Sharedlet is a shared application, e.g. TextChat, VoIP,
Video Conferencing, Shared Applications, Whiteboard
GroupManager provides preliminary Group information to each
sharedlet, include joined sessions, active session, session
participants, participant privileges (e.g. host, presenter) in each
session
Each Sharedlet has its own specific method to handle Group. E.g.


Text Sharedlet stores all conversations in every sessions
 Video Sharedlet displays the videos in the active session only
 Audio Sharedlet plays the audio in the active session only
 Shared Display Sharedlet may store data in every sessions or
in the active session only
The Sharedlet specific method depends on network bandwidth
requirement (e.g. Is the network bandwidth sufficient?) and usage
difference (e.g. Can past data be disposed? Who can share
information?)
Video
Group
Audio
Text
HSD – Hybrid Shared Display



HSD builds on a combination of Classic Shared Display (CSD)
and Video Shared Display (VSD)
Problem: Video sharing using lossless encoding scheme
consumes very high network bandwidth
Motivation of HSD: Find the video or fast changing regions in
the shared application, and encode them using video codec
e.g. H.261 and MPEG4 to save network bandwidth while
retaining good visual quality
Fig. 1: The left window shows an Anabas operational client sharing a browser
window with an embedded video. The window on the right is only for our
debugging purposes and shows the rate of pixel change spatial distribution. The
superimposed red rectangular outline on both windows is identified by a region
finding algorithm operating on right window and used on the left. All pixels inside
the red outline are shared with a video codec; all others use a lossless
compression technique.
47
Illustration of Hybrid Shared Display on
the sharing of a browser window with a
fast changing region.
HSD Flow
Screen capturing
Region finding
VSD
CSD
Video encoding
Through
NaradaBrokering
SD screen data encoding
Presenter
Network transmission (RTP)
Network transmission (TCP)
Participants
Video Decoding (H.261)
SD screen data decoding
Rendering
Rendering
Screen display
GlobalMMCS Web Service Architecture
Use Multiple Media servers to scale to many codecs and many
versions of audio/video mixing
Session Server
XGSP-based Control
NaradaBrokering
All Messaging
NB Scales as
distributed
Admire
Web
Services
SIP
H323
Media Servers
Filters
High Performance (RTP)
and XML/SOAP and ..
Access Grid
Native XGSP
Gateways convert to uniform XGSP Messaging
NaradaBrokering
50
Global-MMCS Community Grid




This includes an open source protocol independent Web Service
“MCU” which will scale to an arbitrary number of users and
provides support for thousands of simultaneous users of
collaboration services.
The function of A/V media server is distributed using
NaradaBrokering architecture.
• Media Servers mix and convert A/V streams
Open XGSP MCU based on the following open source projects
• openh323 is basis of H323 Gateway
• NIST SIP stack is basis of SIP Gateway
• NaradaBrokering is open source messaging
• Java Media Framework basis of Media Servers
• Helix Community http://www.helixcommunity.org for Real
Media
http://www.globalmmcs.org open source release
51
Break up into “Services”

Monolithic MCU becomes many different “Simple Services”
•
•
•
•
•
•
•
•



Session Control
Thumbnail “image” grabber
Audio Mixer
Video Mixer
Codec Conversion
Helix Real Streaming
PDA Conversion
H323/SIP Session/Signaling Gateways
As independent can replicate particular services as needed
• Codec conversion might require 20 services for 20 streams
spread over 5 machines
1000 simultaneous users could require:
• 1 session controller, 1 audio mixer, 10 video mixers, 20 codec
converters, 2 PDA converters and 20 NaradaBrokers
Support with a stream optimized Grid Farm in the sky
• Future billion way “Video over IP” serving 3G Phones and home media
centers/TV’s could require a lot of computing
52
Collaboration Grid
WS-Context
HPSearch
UDDI
Narada
Broker
Audio Mixer
Video Mixer
Narada
Broker
WS-Security
Gateway
XGSP Media
Service
Narada
Broker
Gateway
SharedWS
Transcoder
Thumbnail
Replay
Record
Annotate
SharedDisplay
WhiteBoard
53
GlobalMMCS and NaradaBrokering








All communication – both control and “binary” codecs are
handled by NaradaBrokering
Control uses SOAP and codecs use RTP transport
Each stream is regarded as a “topic” for NB
Each RTP packet from this stream is regarded as an “event” for
this topic
Can use replay and persistency support in NB to support
archiving and late clients
Can build customized stream management to administer replay,
and who gets what stream in what codec
NaradaBrokering supports unicast and multicast
Use firewall penetration and network monitoring services in NB
to improve Q0S
54
XML based General Session Protocol XGSP
The XGSP conference control includes three services:

Conference management
supports user sign-in, user create/terminate/join/leave/inviteinto XGSP conferences
conference calendar service

Application session management
provides users with the service for creating/terminating
application sessions, managing session related services such as
audio/video mixing

Floor control
manages the access to shared collaboration resources in
different application sessions
for example, in a large scale of meetings having thousands of people, only
limited people are allowed to become presenters so that they can send
audio/video
55
Improved Java Media Framework
Performance
60
70
50
60
40
AG VIC
30
SunJMF
20
FastJMF
50
40
SunJMF
30
FastJMF
20
10
10
0
0
1 2 3 4 5 6 7 8
AG VIC
1 2 3 4 5 6 7 8
Video Rendering performance (left: still desktop, right: movie sequence)
We plot CPU percentage use versus number of streams rendered
56
GIS
TV
Chat
Video Mixer
Webcam
GlobalMMCS SWT Client
57
Integration of PDA, Cell phone and Desktop Grid Access
NB Support for optimized
PDA Communication58
Real time annotation and replay I
Opens an
Closes the
eSports session eSports session
Session ID
Session
Description
GlobalMMCS
Video 2
Whiteboard area
(Snapshot annotation
tool area)
GlobalMMCS
Video 1
Snapshot
Button for
Video 2
Snapshot
Button for
Video 1
Timeline
Session List
Session
Information
Area
Stream
Information
Area
Starting and
stopping
replay
sessions and
streams
59
Snapshot during a
recording/annotation session
60
Replay of an annotation session
61
Sensor
and GIS Grids
See also PhD Thesis http://grids.ucs.indiana.edu/ptliupages/publications/GalipAydinThesis.pdf http://grids.ucs.indiana.edu/ptliupages/presentations/galip-aydin-defense.ppt
Paper http://grids.ucs.indiana.edu/ptliupages/publications/PEPIRealTimeGISAydin_YB.pdf
62
Managing Real Time GPS
Data
PhD of Galip Aydin
63
California Real Time Network
Continuous GPS Stations (CGPS) are depicted as
triangles while the Real-Time stations are
represented as circles. Image is obtained from
SOPAC GPS Explorer at
http://sopac.ucsd.edu/projects/realtime
Message Format
Network Data Rates
CRTN GPS
Site Positions
(9 Stations)
Entire SCIGN
Network (250
stations)
Time
RYO
ASCII
GML
1 second
1.5KB
4.03KB
48.7KB
1 hour
5.31MB
14.18MB
171.31MB
1 day
127.44MB
340.38MB
4.01GB
1 month
3.8GB
9.97GB
123.3GB
1 year
45.8GB
119.67GB
1.41TB
1year
1.23TB
16.18TB
160TB
How does one manage all the data generated by the
85 stations? How can you get just the data you want?
Note this is fundamentally different from traditional
request/response style Web Services.
64
Processing Real-Time GPS Streams
ascii2gm
l
ryo2as
cii
RYO
Ports
ascii2po
s
7010
Raw Data
Scripp
s
RTD
Server
7011
NB
Server
ryo2nb
Single
Station
7012
Displaceme
nt Filter
GPS Networks
RDAHMM
Filter
Raw
Data
ryo2nb
ryo2as
cii
ascii2po
s
Station
Health
Filter
Single
Station
RDAHMM
Filter
/SOPAC/GPS/CRTN01/R
YO
/SOPAC/GPS/CRTN01/A
SCII
/SOPAC/GPS/CRTN01/P
OS
/SOPAC/GPS/CRTN01/DS
ME
A Complete Sensor Message Processing Path, including a data analysis application.
65 65
Application Integration with Real-Time Filters I


Station Monitor Filter
records real-time
positions for 10 minutes
and calculates position
changes
Graph Plotter Application
creates visual
representation of the
positions.
66 66
Application Integration with Real-Time Filters II


RDAHMM Filter records
real-time positions for 10
minutes and invokes
RDAHMM application
which determines state
changes in the XYZ signal.
Graph Plotter Application
creates visual
representation of the
RDAHMM output.
67 67
2 – Multiple Publishers Test
Multiple Publishers Test
6
5
2
1
Time Of The Day
Simple
Filter
Transfer Time
 We add more GPS networks by running more publishers.
 The results show that 1000 publishers can be supported
with no performance loss. This is an operating system 68
68
limit.
22:30
21:00
19:30
18:00
16:30
15:00
13:30
12:00
10:30
9:00
7:30
6:00
0
4:30
Topi
c 1B
RYO
Publisher
n
0:00
RYO To
ASCII
Converter
NB Topi
cn
Server
3
3:00
Topi
c 1A
4
1:30
Topi
c2
Time (ms)
RYO
Publisher
1
RYO
Publisher
2
4 – Multiple Brokers Test
 NaradaBrokering allows
RYO
Publisher
RYO To
ASCII
Converter
Topi
c 1A
NB
Server
1
Topi
c 1B
Simpl
e
Filter
Simpl
1
e
Filter
2
Simple
Filter
750
Simple
Filter
751
NB
Serv
er 2
NB
Server
2
Simple
Filter
752
Topi
c 1B
Simple
Filter
1500
creation of Broker networks.
 We create a two-broker
network.
 Messages published to first
broker can be received from
the second broker.
 We take timings on each
broker.
 We connect 750 clients to
each broker and run for 24
hours. We chose 750 clients to
stay well below the saturation
limit.
 The results show that the
performance is very good and
69 69
similar to single broker test.
Federating Geographical
Information Systems
70
Integrating Map Servers



Geographical Information Systems combine online dynamic
maps and databases.
Many GIS software packages exist
GIS servers around state of Indiana




ESRI ArcIMS and ArcMap Server (Marion, Vanderburgh,
Hancock, Kosciusco, Huntington, Tippecanoe)
Autodesk MapGuide (Hamilton, Hendricks, Monroe,
Wayne)
WTH Mapserver™ Web Mapping Application (Fulton,
Cass, Daviess, City of Huntingburg) based on several
Open Source projects (Minnesota Map Server)
Challenge: make 17 different county map servers from different
companies work together.

92 counties in Indiana, so potentially 92 different map
servers.
71
Considerations
 We assume heterogeneity in GIS map and feature
servers.
 GIS services are organized bottom-up rather than top-down.
 Local city governments, 92 different county governments,
multiple Indiana state agencies, inter-state (Ohio, Kentucky)
consideration, federal government data providers (Hazus).
 Must find a way to federate existing services.
 We must reconcile ESRI, Autodesk, OGC, Google Map,
and other technical approaches.
 Must try to take advantage of Google, ESRI, etc rather than
compete.
 We must have good performance and interactivity.
 Servers must respond quickly--launching queries to 20 different
map servers is very inefficient.
 Clients should have simplicity and interactivity of Google Maps
and similar AJAX style applications.
72
Caching and Tiling Maps
 Federation through caching:
 WMS and WFS resources are queried and results are stored on the
cache servers.
 WMS images are stored as tiles.
 These can be assembled into new images on demand (c. f. Google
Maps).
 Projections and styling can be reconciled.
 We can store multiple layers this way.
 We build adapters that can work with ESRI and OGC products; tailor to
specific counties.
 Serving images as tiles
 Client programs obtain images directly from our tile server.
 That is, don’t go back to the original WMS for every request.
 Similar approaches can be used to mediate WFS requests.
 This works with Google Map-based clients.
 The tile server can re-cache and tile on demand if tile sections are
missing.
73
Google Maps Server
Marion County
Map Server
(ESRI ArcIMS)
Must provide adapters
for each Map Server
type .
Tile Server requests
map tiles at all zoom
levels with all layers.
These are converted
to uniform projection,
indexed, and stored.
Overlapping images
are combined.
Hamilton
County Map
Server
(AutoDesk)
Adapter
Adapter
Adapter
Tile Server
Cache Server
Browser +
Google Map
API
Cass County
Map Server
(OGC Web Map
Server)
Browser client fetches
image tiles for the
bounding box using
Google Map API.
The cache server
fulfills Google map
calls with cached tiles
at the requested
bounding box that fill
the bounding box.
74 74
Map Server Example
Marion and Hancock
county parcel plots and
IDs are overlaid on IU
aerial photographic
images that are
accessed by this
mashup using Google
Map APIs.
We cache and tile all
the images from several
different map servers.
(Marion and Hancock
actually use different
commercial software.)
75