1. Web Services and Grid Architecture and their application to Earthquake Science
Beijing
China National Grid
Jade Palace Hotel
August
Geoffrey Fox
Community Grids Lab
Indiana University

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

3. Web services
Web Services build loosely-coupled, distributed applications, based on the SOA principles.
Web Services interact by exchanging messages in SOAP format
The contracts for the message exchanges that implement those interactions are described via WSDL interfaces.

4. 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 Report UKeS ,
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.

5. 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 interactive real-time sessions
Resources such as databases supporting (larger) communities

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

7. Large and Small Grids
N resources in a community (N is billions for the world and for many scientific fields)
Communities are arranged hierarchically with real work being done in “groups” of M resources – M could be 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 M2 Grids
Nature of Interaction depends on size of M or N
N plus N Shared Information Grids for largish N
M2 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 M2 Systems

8. M2 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

9. 4 Overlay Networks With a 5th superimposed
Dynamic light-weight Peer-to-peer
Collaboration Training Grid
Enterprise Grid
Students
Information Grid
Compute Grid R2 R1
Campus Grid
Teacher
4 Overlay Networks
With a 5th superimposed

10. 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 M2 case

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

12. 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. Service Discovery
c. Security
d. Messaging
e. Notification
f. Workflow and Coordination
g. Characteristics
h. Metadata and State
i. User Interfaces

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

14. A List of Web Services II
c) Security
SAML Security Assertion Markup Language (OASIS) V1.1 May 2004
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

15. A List of Web Services III
d) Messaging
WS-Addressing Web Services Addressing (BEA, IBM, Microsoft) March 2004
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 Web Services Eventing (BEA, Microsoft, TIBCO) January 2004
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

16. 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 Web Services Coordination (BEA, IBM, Microsoft) September 2003
WS-AtomicTransaction Web Services Atomic Transaction (BEA, IBM, Microsoft) September 2003
WS-BusinessActivity Web Services Business Activity Framework (BEA, IBM, Microsoft) January 2004
BTP Business Transaction Protocol (OASIS) May 2002 with V May 2004
BPEL Business Process Execution Language for Web Services (OASIS) V1.1 May 2003
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

17. 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 (OASIS) Oasis TC set up April 2004 and V1.1 Framework March 2004
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

18. 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 Portlet Specification for Java binding (Java Community Process) October 2003

19. 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." 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

20. Web Services Grids and WS-I+
WS-I Interoperability doesn’t cover all the capabilities need to support Grids
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 best practice and support will probably get added soon
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”

21. 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
Service Context
Service Internet
Base Hosting Environment
Protocol HTTP FTP DNS …
Presentation XDR …
Session SSH …
Transport TCP UDP …
Network IP …
Data Link / Physical
Bit level
Internet
(OSI
Stack)
Layered Architecture for Web Services and Grids

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

23. Consequences of Rule of the Millisecond
Useful to remember critical time scales
1) ms – CPU does a calculation
2) to 0.01 ms – 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

24. Linking Modules
Module A
Module B
Method Calls .001 to 1 millisecond
Service A
Service B
Messages
0.1 to 1000 millisecond latency
Coarse Grain Service Model
Closely coupled Java/Python …
From method based to RPC to message based to event-based
Service B
Service A
“Listener” Subscribe to Events
Publisher
Post Events
Message Queue in the Sky

25. 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 projects that are multiple functionalities presented as (Java) globs and NOT (Java) Simple Services
Makes it hard to integrate sharing common security, user profile, file access .. services

26. 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
Overlay
and Compose
Grids of Grids
Methods
Services
Component Grids
CPUs
Clusters
Compute
Resource Grids
MPPs
Databases
Federated
Sensor
Sensor Nets
Data

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

28. … Gas Services and Filters Physical Network Registry Metadata
Flood Services and Filters
Flood CIGrid
Gas CIGrid …
Electricity
CIGrid
Data Access/Storage
Security
Workflow
Notification
Messaging
Portals
Visualization Grid
Collaboration Grid
Sensor Grid
Compute Grid
GIS Grid
Core Grid Services
Critical Infrastructure (CI) Grids built as Grids of Grids

29. Repositories Federated Databases
Sensors
Streaming Data
Field Trip Data
Database
Database
Sensor Grid
Database Grid
Research
Education
SERVOGrid ?
Discovery
Services
GIS Grid
Compute Grid
Customization
Services
From Research to Education
Data Filter Services
Research Simulations
Analysis and Visualization Portal
Education Grid
Computer
Farm
Geoscience Research and Education Grids

30. IOI and CIE Application Specific Grids
Let us study the two layers IOI (Service Internet On the Bit Internet) and CIE (Context and Information Environment)
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

31. NaradaBrokering NaradaBrokering Broker Network Web Service B Queues
Minicomputer
Firewall
Computer
Server
PDA
Modem
Laptop computer
Workstation
Peers
Audio/Video
Conferencing Client
NaradaBrokering Broker
Network
Web Service B
Queues
Stream
Server-enhanced Messaging
NB supports messages
and streams

32. Current NaradaBrokering Features
Multiple transport support
In publish-subscribe
Paradigm with different
Protocols on each link
Transport protocols supported include TCP,  Parallel TCP streams, UDP, Multicast, SSL, HTTP and HTTPS.
Communications through authenticating proxies/firewalls & NATs. Network QoS based Routing
Subscription Formats
Subscription can be Strings, Integers, XPath queries, Regular Expressions, SQL and tag=value pairs.
Reliable delivery
Robust and exactly-once delivery of messages in presence of failures
Ordered delivery
Producer Order and Total Order over a message type
Time Ordered delivery using Grid-wide NTP based absolute time
Recovery and Replay
Recovery from failures and disconnects.
Replay of events/messages at any time.
Security
Message-level WS-Security compatible security
Message Payload options
Compression and Decompression of payloads
Fragmentation a nd Coalescing of payloads
Messaging Related Compliance
Java Message Service (JMS) 1.0.2b compliant
Support for routing P2P JXTA interactions.
Grid Application Support
NaradaBrokering enhanced Grid-FTP. Bridge to the Globus TK3.
Web Service reliability
Prototype implementation of WS-ReliableMessaging

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

34. Virtualizing Communication
Communication specified in terms of user goal and Quality of Service – not in choice of port number and protocol
Bit Internet Protocols have become overloaded e.g. MUST use UDP for A/V latency requirements but CAN’t use UDP as firewall will not support ………
A given “Service Internet” communication can involve multiple transport protocols and multiple destinations – the latter possibly determined dynamically
NB Brokers
Fast Link
Firewall HTTP B1
Satellite UDP A
Hand-Held Protocol B2
Software Multicast
Dial-up Filter
NB Broker B3
Client Filtering

35. Performance Monitoring
Every broker incorporates a Monitoring service that monitors links originating from the node.
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.
Every broker in NaradaBrokering incorporates a monitoring service (as shown in Figure 12) that monitors the state of the links originating from the broker node. Metrics computed and reported over individual links, originating from a broker node, include bandwidth, jitter, transit delays, loss rates and system throughputs.
Factors are measured in a non-intrusive way so as to ensure that the measurements do not further degrade the metrics being measured in the first place. Factors such as bandwidth measurements, which can pollute other metrics being measured, are measured at lesser frequencies. Furthermore, once a link is deemed to be at the extreme ends of the performance spectrum (either very good or very bad) the measurement of certain factors are turned off while others are measured at a far lower frequency.
The monitoring service then reports this data to a performance aggregator node, which aggregates information from monitoring services running at other nodes.

36. NaradaBrokering Service IntegrationP2 P1
Proxy Messaging S1 S2
Handler Messaging S1 S2
Notification 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++

37. Mechanisms for Reliable Messaging I
Service B
Service A
M(n+1)
M(n)
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

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

39. 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
NaradaBroker
Filter 1
Filter 2
WS-RM
WS-Reliability

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

41. 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)
Pure SOAP SOAP over UDP Binary over UDP
7020
5.60

42. Fast Web Service Communication II
Mechanism only works for streams – sets of related messages
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

43. 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 Fast transport (On a different port) with messages just having “FlexibleRepresentationContextToken”, Sequence Number, Time stamp if needed
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

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

45. Four Metadata Architectures
System or Federated Registry or Metadata Catalog
Database
Grid or Domain Specific Metadata Catalogs
Database1
Database2
Database3
Web Service Ports
SDE1 SDE2 Service
Individual Services M
Messages

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

47. 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 1 2 3 4
Explicit
instances F A C T O R Y 1 2 3 4
Hidden
instances
Implicit Factory
Explicit Factory

48. Notification Architecture
Point-to-Point
Or Brokered
NaradaBrokering will support both WS-Eventing and WS-Notification as well as Java Message Service JMS that is Java Notification standard
Service B
Service A
Publish
Subscribe
Service B
Service A
Broker
Publish
Subscribe
Queues Messages
Supports creation
and subscription of topics