Web Services and Grid Architecture and their application to Earthquake Science Beijing China National Grid Jade Palace Hotel August 26 2004 Geoffrey Fox Community Grids Lab Indiana University [email protected].
Download ReportTranscript Web Services and Grid Architecture and their application to Earthquake Science Beijing China National Grid Jade Palace Hotel August 26 2004 Geoffrey Fox Community Grids Lab Indiana University [email protected].
Web Services and Grid Architecture and their application to Earthquake Science
Beijing China National Grid Jade Palace Hotel August 26 2004 Geoffrey Fox Community Grids Lab Indiana University [email protected]
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 organization and proposed infrastructure – and Java was considered too complicated in both 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
Web services
• Web Services principles. build loosely-coupled, distributed applications, based on the SOA • Web Services interact by exchanging messages in SOAP format • The contracts for the message exchanges that implement those interactions are described via WSDL interfaces.
Databases Devices Programs Computational resources
SOAP messages Humans
What is a Grid?
• You won’t find a clear description of what is Grid and how does differ from a collection of Web Services – I see no essential reason that Grid Services have different requirements than Web Services – Geoffrey Fox, David Walker,
e-Science Gap Analysis
, June 30 2003. Report UKeS-2003-01, http://www.nesc.ac.uk/technical_papers/UKeS-2003-01/index.html
. – Notice “service-building model” is like programming language – very personal!
• Grids were once defined as “ Internet Scale Distributed Computing ” but this isn’t good as Grids depend as much if not more on data as well as simulations • So Grids can be termed “ Internet Scale Distributed Services ” and represent a way of collecting services together to solve problems where special features and quality of service needed.
e-Infrastructure
e-Infrastructure builds on the inevitable increasing performance of networks and computers linking them together to support new flexible linkages between computers, data systems and people
•
Grids and peer-to-peer networks are the technologies that build e-Infrastructure
•
e-Infrastructure called CyberInfrastructure in USA We imagine a sea of conventional local or global connections supported by the “ordinary Internet”
•
Phones, web page accesses, plane trips, hallway conversations
•
Conventional Internet technology manages billions of broadcast or low (one client to Server) or broadcast links On this we superimpose high value multi-way organizations (linkages) supported by Grids with optimized resources and system support
• •
Low multiplicity fully Resources such as interactive real-time sessions databases supporting (larger) communities
N plus N Community Resources
Grid Community databases have analogy to Television and the News Web that allow individuals to communicate instantly with each other via Web Pages and Headline News acting as proxies N resources deposit information and N can view
Call N plus N
Large and Small Grids
N resources in a community (N is billions for the world and 1000 10000 for many scientific fields) Communities are arranged hierarchically with real work being done in “groups” of M resources – M could be 10-100 in e-Science Metcalfe’s law : value of network grows like square of number of nodes M – we call Grids where this true Metcalfe or M 2 Grids Nature of Interaction depends on size of M or N
• •
N plus N M 2
Shared Information Grids for largish N
Metcalfe Grids for smaller M < N Technology support depends on M/N – might use a relatively static DHT (Distributed Hash Table) for large N and a distributed shared memory for small M Grids must merge with peer-to-peer networks to support both
N plus N
and
M 2
Systems
M
2
Interactions
• Superimpose M way “Grids” on the sea (heatbath) of “2 by N” or N plus N “ordinary” interactions Grids also support many community N plus N resources Implement Grids as a software overlay network
Dynamic light-weight Peer-to-peer Collaboration Training Grid
Enterprise Grid Students Information Grid R1 R2 Teacher Campus Grid Compute Grid
4 Overlay Networks With a 5 th superimposed
Architecture of (Web Service) Grids
Grids built from Web Services communicating through an overlay network built in SOFTWARE on the “ordinary internet” at the application level Grids provide the special quality of service (security, performance, fault-tolerance) and customized services needed for “distributed complex enterprises” We need to work with Web Service community as they debate the 60 or so proposed Web Service specifications
• • • •
Use Web Service Interoperability WS-I as “best practice” Must add further specifications to support high performance Database “Grid Services” for
N plus N
case Streaming support for
M 2
case
Importance of SOAP
• SOAP defines a very obvious message structure with a
header
and a
body
• The
header
contains information used by the “
Internet operating system
” – Destination, Source, Routing, Context, Sequence Number … • The
message body
is only used by the
application
and will never be looked at by “operating system” except to encrypt, compress it etc.
• Much discussion in field revolves around
what is in header!
– e.g. WSRF adds a lot to header
Web Services
• Java is very powerful partly due to its many “frameworks” that generalize libraries e.g.
– Java Media Framework – Java Database Connectivity JDBC • Web Services have a correspondingly collections of specifications that represent critical features of the distributed operating systems for “Grids of Simple Services” – Some 60 active WS-* specifications for areas such as –
a.
Core Infrastructure Specifications
– – –
b.
c.
d.
Service Discovery Security Messaging
– – – – –
e.
f.
g.
h.
i.
Notification Workflow and Coordination Characteristics Metadata and State User Interfaces
• • • • • • • • • •
A List of Web Services I
a) Core Service Architecture XSD
XML Schema (W3C Recommendation) V1.0 February 1998, V1.1 February 2004
WSDL 1.1
Web Services Description Language Version 1.1, (W3C note) March 2001
WSDL 2.0
Web Services Description Language Version 2.0, (W3C under development) March 2004
SOAP 1.1
(W3C Note) V1.1 Note May 2000
SOAP 1.2
(W3C Recommendation) June 24 2003
b) Service Discovery UDDI
(Broadly Supported OASIS Standard) V3 August 2003
WS-Discovery
Web services Dynamic Discovery (Microsoft, BEA, Intel …) February 2004
WS-IL
Web Services Inspection Language, (IBM, Microsoft) November 2001
• • • • • • • •
A List of Web Services II
c) Security SAML
2004 Security Assertion Markup Language (OASIS) V1.1 May
XACML
eXtensible Access Control Markup Language (OASIS) V1.0 February 2003
WS-Security 2004
Web Services Security: SOAP Message Security (OASIS) Standard March 2004
WS-SecurityPolicy
Web Services Security Policy (IBM, Microsoft, RSA, Verisign) Draft December 2002
WS-Trust
Web Services Trust Language (BEA, IBM, Microsoft, RSA, Verisign …) May 2004
WS-SecureConversation
Web Services Secure Conversation Language (BEA, IBM, Microsoft, RSA, Verisign …) May 2004
WS-Federation
Web Services Federation Language (BEA, IBM, Microsoft, RSA, Verisign) July 2003
• • • • • • • • • • •
d) Messaging
A List of Web Services III
WS-Addressing
March 2004 Web Services Addressing (BEA, IBM, Microsoft)
WS-MessageDelivery
Web Services Message Delivery (W3C Submission by Oracle, Sun ..) April 2004
WS-Routing
Web Services Routing Protocol (Microsoft) October 2001
WS-RM
Web Services Reliable Messaging (BEA, IBM, Microsoft, Tibco) v0.992 March 2004
WS-Reliability
Web Services Reliable Messaging (OASIS Web Services Reliable Messaging TC) March 2004
SOAP MOTM
SOAP Message Transmission Optimization Mechanism (W3C) June 2004
e) Notification WS-Eventing
2004 Web Services Eventing (BEA, Microsoft, TIBCO) January
WS-Notification
Framework for Web Services Notification with
WS Topics , WS-BaseNotification ,
and
WS-BrokeredNotification
(OASIS) OASIS Web Services Notification TC Set up March 2004
JMS
Java Message Service V1.1 March 2002
• • • • • • • • • • • • •
A List of Web Services IV
f) Coordination and Workflow, Transactions and Contextualization WS-CAF
Web Services Composite Application Framework including
WS-CTX , WS-CF
and
WS-TXM
below (OASIS Web Services Composite Application Framework TC) July 2003
WS-CTX
Web Services Context (OASIS Web Services Composite Application Framework TC) V1.0 July 2003
WS-CF
Web Services Coordination Framework (OASIS Web Services Composite Application Framework TC) V1.0 July 2003
WS-TXM
Web Services Transaction Management (OASIS Web Services Composite Application Framework TC) V1.0 July 2003
WS-Coordination
2003 Web Services Coordination (BEA, IBM, Microsoft) September
WS-AtomicTransaction
September 2003 Web Services Atomic Transaction (BEA, IBM, Microsoft)
WS-BusinessActivity
Web Services Business Activity Framework (BEA, IBM, Microsoft) January 2004
BTP
Business Transaction Protocol (OASIS) May 2002 with V1.0.9.1 May 2004
BPEL
2003 Business Process Execution Language for Web Services (OASIS) V1.1 May
WS-Choreography
(W3C) V1.0 Working Draft April 2004
WSCI
(W3C) Web Service Choreography Interface V1.0 (W3C Note from BEA, Intalio, SAP, Sun, Yahoo)
WSCL
Web Services Conversation Language (W3C Note) HP March 2002
• • • • • • • • • • •
A List of Web Services V
h) Metadata and State RDF
Resource Description Framework (W3C) Set of recommendations expanded from original February 1999 standard
DAML+OIL
combining DAML (Darpa Agent Markup Language) and OIL (Ontology Inference Layer) (W3C) Note December 2001
OWL
Web Ontology Language (W3C) Recommendation February 2004
WS-DistributedManagement
Web Services Distributed Management Framework with MUWS and MOWS below (OASIS)
WSDM-MUWS
Web Services Distributed Management: Management Using Web Services (OASIS) V0.5 Committee Draft April 2004
WSDM-MOWS
Web Services Distributed Management: Management of Web Services (OASIS) V0.5 Committee Draft April 2004
WS-MetadataExchange
Web Services Metadata Exchange (BEA,IBM, Microsoft, SAP) March 2004
WS-RF
Web Services Resource Framework including
WS-ResourceProperties , WS-ResourceLifetime , WS-RenewableReferences , WS-ServiceGroup ,
and
WS-BaseFaults
2004 (OASIS) Oasis TC set up April 2004 and V1.1 Framework March
ASAP
Asynchronous Service Access Protocol (OASIS) with V1.0 working draft G June 2004
WS-GAF
Web Service Grid Application Framework (Arjuna, Newcastle University) August 2003
A List of Web Services VI
• • • • • • •
g) General Service Characteristics WS-Policy
Web Services Policy Framework (BEA, IBM, Microsoft, SAP) May 2003
WS-PolicyAssertions
Web Services Policy Assertions Language (BEA, IBM, Microsoft, SAP) May 2003
WS-Agreement
Web Services Agreement Specification (GGF under development) May 2004
i) User Interfaces WSRP
Web Services for Remote Portlets (OASIS) OASIS Standard August 2003
JSR168 :
JSR-000168 Portlet Specification for Java binding (Java Community Process) October 2003
WS-I Interoperability
• Critical underpinning of Grids and Web Services is the gradually growing set of specifications in the Web Service Interoperability Profiles • Web Services Interoperability (WS-I) Interoperability Profile 1.0a." http://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.
• 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
•
Web Services Grids and WS-I+
WS-I
Interoperability support Grids doesn’t cover all the capabilities need to •
WS-I+
is designed to minimal extension of WS-I to support “most current” Grids: it adds support for – Enhanced SOAP Addressing (WS-Addressing) – Fault tolerant (reliable) messaging – Workflow as in IBM-Microsoft standard BPEL • Security and Notification get added soon best practice and support will probably – There are Web Service frameworks here but various IBM v Microsoft v Globus differences to be resolved • Portlet-based User Interfaces could be added • UK OMII Open Middleware Infrastructure Institute is adopting this approach to support UK e-Science program – Currently UK e-Science largely either uses GT2 (as in EDG) or Simple Web Services for “database Grids” – http://www.omii.ac.uk/
Application Specific Grids Generally Useful Services and Grids Workflow WSFL/BPEL Service Management (“Context etc.”) Service Discovery (UDDI) / Information Service Internet Transport
Protocol Service Interfaces WSDL Base Hosting Environment Protocol HTTP FTP DNS … Presentation XDR … Session SSH … Transport TCP UDP … Network IP … Data Link / Physical Higher Level Services Service Context Service Internet Bit level Internet (OSI Stack) Layered Architecture for Web Services and Grids
Working up from the Bottom
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) 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
Consequences of Rule of the Millisecond
• Useful to remember critical time scales – 1) 0.000001 ms – 2) 0.001 to 0.01 ms – CPU does a calculation – MPI latency – 3) 1 to 10 ms – wake-up a thread or process – 4) 10 to 1000 ms – Internet delay • 4) implies geographically distributed metacomputing can’t in general compete with parallel systems (OK for some cases) • 3) << 4) implies RPC not a critical programming abstraction as it ties distributed entities together and gains a time that is typically only 1% of inevitable network delay – However many service interactions are at their heart RPC but implemented differently at times e.g. asynchronously • 2) says MPI is not relevant for a distributed environment as low latency cannot be exploited • Even more serious than using RMI/RPC, current Object paradigms also lead to mixed up services with unclear boundaries and autonomy • Web Services are only interesting model for services today
Linking Modules
Closely coupled Java/Python … Coarse Grain Service Model Module B Module A Method Calls .001 to 1 millisecond Service B Messages Service A 0.1 to 1000 millisecond latency
From method based to RPC to message based to event-based
“Listener” Subscribe to Events
Service B
Message Queue in the Sky Publisher Post Events
Service A
What is a Simple Service?
• Take any system – it has service multiple functionalities – We can implement each functionality as an independent distributed – Or we can bundle multiple functionalities in a single service • Whether functionality is an independent service or one of many method calls into a “ • Simple services glob of software ”, we can always make them as Web services by converting interface to WSDL 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 projects that are multiple functionalities presented as ( Java) globs file access .. services and NOT (Java) Simple Services – Makes it hard to integrate sharing common security, user profile,
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 Services Component Grids CPUs Databases Clusters MPPs Federated Databases Compute Resource Grids Data Resource Grids Sensor Sensor Nets Overlay and Compose Grids of Grids
Component Grids?
• So we build collections of Web Services which we package as
component Grids
– Visualization Grid – Sensor Grid – Utility Computing Grid – Person (Community) Grid – Earthquake Simulation Grid – Control Room Grid – Crisis Management Grid • We build bigger Grids by
composing component Grids
using the
Service Internet
Flood CIGrid Flood Services and Filters
…
Electricity CIGrid
…
Gas CIGrid Gas Services and Filters Collaboration Grid Sensor Grid Portals GIS Grid Registry Security Data Access/Storage
Core Grid Services
Notification Workflow Physical Network Visualization Grid Compute Grid Metadata Messaging
Critical Infrastructure (CI) Grids built as Grids of Grids
Field Trip Data Repositories Federated Databases Database Database Sensors Streaming Data Sensor Grid Database Grid Research Education SERVOGrid
Data Filter Services
Compute Grid Research Simulations ?
Discovery Services
GIS Grid Analysis and Visualization Portal
Customization Services From Research to Education
Education Grid Computer Farm
Geoscience Research and Education Grids
IOI and CIE
• Let us study the two layers IOI ( Service I nternet O n the Bit I nternet) and CIE ( C ontext and I nformation E nvironment) • IOI is most “straightforward” as it is providing reasonably well understood capabilities at a new “level” • CIE is roughly the inter-service “shared memory” used to manage and control them at “distributed operating system level – Critical is “shared” (a database service) versus message based CIE
Application Specific Grids Generally Useful Services and Grids Workflow WSFL/BPEL Service Management (“Context etc.”) Service Discovery (UDDI) / Information Service Internet Transport
Protocol Service Interfaces WSDL Higher Level Services CIE IOI
NaradaBrokering
Audio/Video Conferencing Client
Computer Modem
NaradaBrokering Broker Network
Minicomputer Firewall Stream Server-enhanced Messaging Workstation Peers PDA Server Web Service B Peers Queues Laptop computer
Audio/Video Conferencing Client NB supports messages and streams
Current NaradaBrokering Features
Multiple transport support In publish-subscribe Paradigm with different Protocols on each link Subscription Formats Reliable delivery Ordered delivery Recovery and Replay Security Message Payload options Messaging Related Compliance Grid Application Support Transport protocols supported include TCP, Parallel TCP streams, UDP, Multicast, SSL, HTTP and HTTPS.
Communications through authenticating proxies/firewalls & NATs. Network QoS based Routing Subscription can be Strings, Integers, XPath queries, Regular Expressions, SQL and tag=value pairs.
Robust and exactly-once delivery of messages in presence of failures Producer Order and Total Order over a message type Time Ordered delivery using Grid-wide NTP based absolute time Recovery from failures and disconnects.
Replay of events/messages at any time.
Message-level WS-Security compatible security Compression and Decompression of payloads Fragmentation a nd Coalescing of payloads Java Message Service (JMS) 1.0.2b compliant Support for routing P2P JXTA interactions.
NaradaBrokering enhanced Grid-FTP. Bridge to the Globus TK3.
Web Service reliability Prototype implementation of WS-ReliableMessaging
NaradaBrokering and IOI
• “Software Overlay Network” features • Support for Multiple Transport protocols • Support for multiple delivery mechanisms – Reliable Delivery – Exactly-once Delivery – Ordered Delivery – Optional Delivery optimization modules for different modes • Compression/Decompression of payloads with optional module • Coalescing/Fragmentation of payloads with optional module • NTP Time Service • Security Service • Performance Monitoring • Performance optimized routing with optional module • Support for WS-Reliability, WS-ReliableMessaging and their Federation
Virtualizing Communication
Communication specified in terms of user goal Service and Quality of – not in choice of port number and protocol Bit Internet Protocols have become firewall will not support ……… overloaded e.g. MUST use UDP for A/V latency requirements but CAN’t use UDP as A given “ Service Internet ” communication can involve multiple transport protocols and multiple destinations – the latter possibly determined dynamically NB Brokers
Fast Link A Satellite UDP Firewall HTTP B 1
NB Broker Software Multicast Client Filtering
Hand-Held Protocol Dial-up Filter B 3 B 2
Performance Monitoring
Every broker incorporates a Monitoring service monitors links originating from the node.
that Every link measures and exposes a set of metrics
•
Average delays, jitters, loss rates, throughput.
Individual links can disable measurements for individual or the entire set of metrics.
Measurement intervals can also be varied Monitoring Service, returns measured metrics to Performance Aggregator .
Broker Node Link Data Monitoring Service Aggregates info from nodes in a certain domain Link Data Performance Aggregation Service Broker Node Control Message Exchange
NaradaBrokering Service Integration
S1 P1 P2 S2 Proxy Messaging Handler Messaging S1 S2 Notification S1 S2 S?
Service P?
Proxy
Any Transport NB Transport Standard SOAP Transport Internal to Service: SOAP Handlers/Extensions/Plug-ins Java (JAX RPC) .NET Indigo and special cases: PDA's gSOAP, Axis C++
Mechanisms for Reliable Messaging I
Service B Service A
M(n) M(n+1) • There are essentially sequence numbers on each message • Unreliable transmission detected by non-arrival of a message with a particular sequence number • Remember this is “just some TCP reliability” built at application level • One can either use ACK’s – Receiver (service B) positively acknowledges messages when received – Service A fully responsible for reliability • Or NAK’s – Service B is partially responsible and tracks message numbers – sends a NAK if sequence number missing
Mechanisms for Reliable Messaging II
• Each message has a retransmission time; messages are retransmitted if ACK’s not received in time – Uses some increasing time delay if retransmit fails • Note need to be informed (eventually) that OK to throw away messages at sender; pure NAK insufficient • Note this is reliability from final end-point to beginning end-point: TCP reliability is for each link and has different grain size and less flexible reliability mechanisms • There are several efficiency issues – Divide messages into groups and sequence within groups – Do not ACK each message but rather sequences of messages • NAK based system attractive if high latency (some mobile devices) on messaging from receiver back to sender
Custom Message Reliability
2 second PDA reply latency!
Different endpoints may well need different reliability schemes. Another reason to use application layer.
Need to define easy to use “standard reliability profiles
Wireless Optimized WS-RM Filter 2 Narada Broker WS-RM WS-Reliability Filter 1
NaradaBrokering and Fault Tolerance
• As well as reliable messaging, NaradaBrokering supports performance based dynamic routing – Choose both route and protocol (UDP, Parallel TCP ..) • It will also support automatic fail-over among replicated services subscribing to same message stream • Provides scriptable control of streams for custom management schemes • Saves ALL messages in fault tolerant storage for either session replay or recovery • Will support reliable BitTorrent P2P file swapping model (better than GridFTP?)
GridFTP plus NaradaBrokering
Fast Web Service Communication I
• IOI Application level Internet allows one to optimize message streams at the cost of “startup time”, Web Services can deliver the fastest possible interconnections with or without reliable messaging • Typical results from Grossman (UIC) comparing Slow SOAP over TCP with binary and UDP transport (latter gains a factor of 1000 ) Record Count 10000 50000 150000 375000 1000000 5000000 MB 0.93 4.65 13.9 34.9 93 465 µ 2.04 8.21 26.4 75.4 278 σ/µ 6.45% 1.57% 0.30% 0.25% 0.11% 2.23% WS-DMX/ASCII MB µ σ/µ 0.5 2.4 7.2 18 48 242 1.47 1.79 2.09 3.08 3.88 8.45 0.61% 0.50% 0.62% 0.29% 1.73% 6.92% MB WS-DMX/Binary µ σ/µ 0.28 1.4 4.2 10.5 28 140 1.45 1.63 1.94 2.11 3.32 0.38% 0.27% 0.85% 1.11% 0.25% 8.12%
Fast Web Service Communication II
• Mechanism only works for
streams
messages – sets of related
• SOAP header in streams is constant
except for sequence number (Message ID), time-stamp ..
• One needs two types of new Web Service Specification • “
WS-StreamNegotiation
” to define how one can use WS-Policy to send messages at start of a stream to define the methodology for treating remaining messages in stream • “
WS-FlexibleRepresentation
” to define new encodings of messages
Fast Web Service Communication III
• Then use “WS-StreamNegotiation” to negotiate stream in Tortoise SOAP – ASCII XML over HTTP and TCP – – Deposit basic SOAP header through connection – it is part of context for stream (linking of 2 services) – Agree on firewall penetration, reliability mechanism, binary representation and fast transport protocol – Naturally transport UDP plus WS-RM • Use “WS-FlexibleRepresentation” to define encoding of a Time stamp if needed Fast transport (On a different port) with messages just having “FlexibleRepresentationContextToken”, Sequence Number, – RTP packets have essentially this structure – Could add stream termination status • Can monitor and control with original negotiation stream • Can generate different streams optimized for different end-points
CIE: Common Service Information and Metadata
• Consider a collection of services working together – Workflow tells you how to specify service interaction but more basically there is shared information or context specifying/controlling collection • WS-RF and WS-GAF have different approaches to contextualization – supplying a common “context” which at its simplest is a token to represent state • More generally core shared information includes dynamic service metadata and the equivalent of configuration information.
• One can supports such a common context either as pool of messages or as message-based access to a “database” (Context Service) • Two services linked by a stream are perhaps simplest example of a collection of services needing context • Note that there is a tension between storing metadata in messages and services . – This is shared versus distributed memory debate in parallel computing
Four Metadata Architectures
System or Federated Registry or Metadata Catalog Database Database1 Grid or Domain Specific Metadata Catalogs Database2 Web Service Ports Database3 SDE1 SDE2 Service
M M
SDE1 SDE2 Service
M
SDE1 SDE2 Service SDE1 SDE2 Service SDE1 SDE2 Service
M
Individual Services
M M M
Messages
M M
SDE1 SDE2 Service
M M
SDE1 SDE2 Service
M
• •
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
Explicit and Implicit Factories
• Stateful interactions are typified by amazon.com where messages carry correlation information allowing multiple messages to be linked together – Amazon preserves state in this fashion which is in fact preserved in its database permanently • Stateful services have state that can be queried outside a particular interaction • Also note difference between implicit and explicit factories – Some claim that implicit factories scale as each service manages its own instances and so do not need to worry about registering instances and lifetime management
F A C T O R Y
Implicit Factory
1 2 3 4
Hidden instances Explicit instances
1 2 3 4
Explicit Factory
F A C T O R Y
Notification Architecture
• Point-to-Point
Service B Service A Subscribe Publish
• Or Brokered
Subscribe Broker Publish Service B
Queues Messages Supports creation and subscription of topics
Service A
• NaradaBrokering will support both WS-Eventing and WS-Notification as well as Java Message Service JMS that is Java Notification standard