WS-Resource Framework and WS-Notification
Technical Overview
Globus World
San Francisco, CA
Wednesday, January 20st, 2004
Jeffrey Frey (IBM)
Steve Graham (IBM)
Tom Maguire (IBM)
David Snelling (Fujitsu)
Steve Tuecke (Globus)
What was announced on January 20
 Proposals to extend to Web services
 Driven by requirements from:
• Grid computing
• Systems Management
• Business computing
 Key to infrastructure for
IBMs On Demand Initiative
Grid
Systems
Computing Management
Web
Services
Business
Computing
© 2004 IBM Corporation
© 2004 University of Chicago
2
What was announcing on January 20
 A family of Web services specification proposals
• WS-Resource Framework (WSRF)
• Introduces a design pattern to specify how to use
Web services to access “stateful” components
• Introduce message based publish-subscribe to Web
services
Introduced
January 20
WS-Resource
Properties
Modeling
Stateful
Resources with
Web Services
To be released
WS-Renewable
References
© 2004 IBM Corporation
© 2004 University of Chicago
3
Why Define WSRF?
 Building large-scale systems by composition of
many heterogeneous components demands that
we extract and standardize common patterns
• Use WS-Addressing for referring to resources, with
extensions for stability (WS-RenewableReferences)
• Define resource lifetime management interfaces
• Define resource inspection (WS-ResourceProperties)
and monitoring (WS-Notification) interfaces
• Define base fault representation & groups
 Standardization encourages enhanced tooling
 WSRF is just a start: E.g. WS Distributed
Management (WSDM) defining resource
management framework (probably) on WSRF
© 2004 IBM Corporation
© 2004 University of Chicago
4
Context: Open Grid Services Architecture
 Define a service-oriented architecture …
• the key to effective virtualization
 … to address vital “Grid” requirements
• AKA utility, on-demand, system management,
collaborative computing
 … building on Web services standards
• extending those standards where needed
© 2004 IBM Corporation
© 2004 University of Chicago
5
Grid and Web Services: Convergence
Grid
Started
far apart
in apps
& tech
Have been
converging
?
Web
However, despite enthusiasm for OGSI, adoption
within Web community turned out to be problematic
© 2004 IBM Corporation
© 2004 University of Chicago
6
Concerns
 Too much stuff in one specification
 Does not work well with existing Web services
tooling
 Too object oriented
© 2004 IBM Corporation
© 2004 University of Chicago
7
Grid and Web Services: Convergence
Grid
Started
far apart
in apps
& tech
Have been
converging
WSRF
Web
The definition of WSRF means that Grid and Web
communities can move forward on a common base
© 2004 IBM Corporation
© 2004 University of Chicago
8
Concerns Addressed
 Too much stuff in one specification
WSRF partitions OGSI v1.0 functionality into a
family of composable specifications
 Does not work well with existing Web services
tooling
WSRF tones down the usage of XML Schema
 Too object oriented
WSRF makes an explicit distinction between the
“service” and the stateful “resources” acted
upon by that service
© 2004 IBM Corporation
© 2004 University of Chicago
9
How these proposals relate to OGSA
WS-Resource Framework & WS-Notification are an evolution of OGSI
• OGSA Services can
be defined and
implemented as
Web services
Applications
OGSA Architected Services
• OSGAWS-Resource
can take
Properties
advantage of other
Modeling
Web services
Stateful
standards
Resources with
Web Services
• OGSA can be
implemented using
standard Web
services development
tools
OGSI – Open Grid Services Infrastructure
Web Services
WS-Renewable
References
• Grid applications will
NOT require special
Web services
infrastructure
© 2004 IBM Corporation
© 2004 University of Chicago
Web Services
OGSA Enabled
OGSA Enabled
OGSA Enabled
OGSA Enabled
OGSA Enabled
OGSA Enabled
Security
Workflow
Database
File Systems
Directory
Messaging
OGSA Enabled
OGSA Enabled
OGSA Enabled
Servers
Storage
Network
10
How these proposals relates to other Web
services standards:
Service
Composition
Quality of
Experience
(QoX)
WS-Service Group
WS-Notification
WS-Reliable Messaging
WS-Security
BPEL4WS
WS-Transaction
WS-Resource Lifetime
WS-Resource Properties
WS-Base Faults
Description
WSDL
XSD
Messaging
XML
SOAP
Transports HTTP/HTTPS
© 2004 IBM Corporation
© 2004 University of Chicago
WS-Policy WS-Metadata Exchange
WS-Addressing WS-Renewable References
SMTP
RMI / IIOP
JMS
11
WS-Resource Framework Capabilities
 Specifies how to use XML to describe and access a
resource’s properties
 Clarifies how stateful resources are addressed
 Defines how a resource is created and messages to destroy
resources
 Provides a message subscription and notification
mechanism for Web services
 Outlines how to organize groups of resources and services
 Adds a fault tolerance capability to WS-Addressing
 Defines a standard, extensible format for Web services error
messages
© 2004 IBM Corporation
© 2004 University of Chicago
12
From OGSI to WSRF:
Refactoring and Evolution**
OGSI
WSRF
Grid Service Reference WS-Addressing Endpoint Reference
Grid Service Handle WS-Addressing Endpoint Reference
HandleResolver portType WS-RenewableReferences
Service data defn & access
WS-ResourceProperties
GridService lifetime mgmt WS-ResourceLifeCycle
Notification portTypes WS-Notification
Factory portType Treated as a pattern
ServiceGroup portTypes WS-ServiceGroup
Base fault type WS-BaseFaults
**Draft document at www.globus.org/wsrf soon
© 2004 IBM Corporation
© 2004 University of Chicago
13
Web Services and Stateful Resources
 “State” appears in almost all applications
• Data in a purchase order
• Current usage agreement for resources on a grid
• Metrics associated with work load on a Web server
 There are many possible ways Web services
might model, access and manage state
• The WS-Resource Framework proposes to
standardize this capability for Web services
© 2004 IBM Corporation
© 2004 University of Chicago
14
The WS-Resource framework model
Web Service
Run-time environment
WSDL
Interface
© 2004 IBM Corporation
© 2004 University of Chicago
Web
Service
15
The WS-Resource framework model
Invoking a Web Service
Endpoint
Reference
Run-time environment
message
© 2004 IBM Corporation
© 2004 University of Chicago
message
Interface
address
Web
Service
16
The WS-Resource framework model
 What is a WS-Resource
• Examples of WS-Resources:
– Physical entities (e.g.. processor, communication link, disk drive)
or Logical construct (e.g.. agreement, running task, subscription)
– Real or virtual
– Static (long-lived, pre-existing) or
Dynamic (created and destroyed as needed)
– Simple (one), or Compound (collection)
resource
• Unique - Has a distinguishable identity and
lifetime
• Stateful - Maintains a specific state that can be
materialized using XML
• May be accessed through one or more Web
Services
© 2004 IBM Corporation
© 2004 University of Chicago
17
The WS-Resource framework model
Using a Web service to access a WS-Resource
Endpoint
Reference
id
Resource id
Address
Run-time environment
message
© 2004 IBM Corporation
© 2004 University of Chicago
message
id
Interface
address
resource
Web
Service
contex
t
18
The WS-Resource framework model
Using a Web service to access a WS-Resource
Endpoint
Endpoint
Reference
Reference
id
Run-time environment
message
message
id
Interface
address
resource
Web
Service
resource
context
© 2004 IBM Corporation
© 2004 University of Chicago
19
The WS-Resource framework model
Creating / Locating a WS-Resource
Endpoint
Reference
Run-time environment
message
Endpoint
Reference
id
resource
addres
s
message
Interface
address
Web
Service
Web Service
either locates or
creates a WSResource
© 2004 IBM Corporation
© 2004 University of Chicago
20
The WS-Resource framework model
 WS-Resource Properties
• Resource state and metadata
“Projected” as an XML document
• Query and Set operations
 WS-Resource LifeTime
• Explicit destruction or
“Soft state” time-to-live
• Provides for cleanup
of resource instances
resource
<ProcessorProperties>
<ProcID>5A34C1DE03</ProcID>
<ProcArchitecture>Power6.2</ProcArchitecture>
<ProcSpeedMIPS>400</ProcSpeed>
<ProcCacheMB>256<ProcCache>
<ProcRunning>1</ProcRunning>
</ProcessorProperties>
© 2004 IBM Corporation
© 2004 University of Chicago
21
WS-Notification
 WS-Notification
• Brings enterprise quality publish and subscribe
messaging to Web services
– Loosely coupled, asynchronous messaging in a Web
services context
• WS Notification exploit WS Resource framework
and Web services technologies
© 2004 IBM Corporation
© 2004 University of Chicago
22
WS-Notification
 Subscriber indicates interest in a particular
“Topic” by issuing a “subscribe” request
Subscriber
subscribe
 Broker (intermediary) permits
decoupling Publisher and Subscriber
notify
 “Subscriptions” are WS-Resources
• Various subscriptions are possible
Broker
 Publisher need NOT be a Web Service
notify
notify
subscribe
 Notification may be “triggered” by:
• WS Resource Property value changes
• Other “situations”
 Broker examines current subscriptions
 Brokers may
S
S
S
Publisher
notify
• “Transform” or “interpret” topics
• Federate to provide scalability
© 2004 IBM Corporation
© 2004 University of Chicago
23
WS-Notification
 Characteristics of WS-Notification:
• Web services integration of traditional enterprise
publish/subscribe messaging patterns
– Composes with other Web services technologies
– Facilitates integration between different messaging
middleware environments
• Standardizes the role of Brokers, Publishers,
Subscribers and Consumers
• Provides two forms of publish/subscribe:
direct publishing and brokered publishing
• Standardizes Web service message exchanges for
publishing, subscribing and notification delivery
• Defines XML model of Topics and TopicSpaces to
categorize and organize notification messsages
© 2004 IBM Corporation
© 2004 University of Chicago
24
Bringing it All Together
Scenario: Resource management & scheduling
Grid Scheduler
Grid “Jobs” and “tasks”
Local processor
manager
J
J
Other
of resources
areisalso
a
arekinds
also modeled
using
is “front-ended” with
Grid
“modeled”
as WS-Resources
J
Web Service
WS-Resources
and
A Web service interface
Service
Scheduler
Resource Properties
Level
Blades
R
R
R
WS-Resource used
A
Service Level
to “model” physical
Agreement
processor
is modeledCluster
as a
Storage
resources
WS-Notification
can
be
WS-Resource
used to “inform” the Lifetime of SLA
R R R
R
R when
R scheduler
WS-Resource
Resource
tied
Properties
processor“project”
utilization to the duration
processor
status (like
changes
of the
utilization)
agreement
© 2004 IBM Corporation
© 2004 University of Chicago
25
WS-Resource Framework & WS-Notification
Value:
 To software developers:
• Reduced cost / time to develop software
– Use of existing WS development tools
– Reuse of common components
– Permit interoperation with other vendors components
 To customers
• Increased solution flexibility & interoperability
–
–
–
–
Support heterogeneous distributed computing environment
Create solutions from multiple vendor components
Interoperability with partners using other software
Open reference implementations available
© 2004 IBM Corporation
© 2004 University of Chicago
26
IBM Support for WS-Notification &
WS-Resource Framework
As standards mature and are broadly adopted
 IBM WebSphere Family and related Rational tools
• Provide a runtime environment that supports WS-Resource
Framework and WS-Notification
 WS-* standards and Service Oriented Architecture (SOA)
exploited:
• Including WS-Security, WS-Reliable Messaging,
WS-Resource Framework, WS-Notification etc.
• Fundamental to IBM’s OnDemand operating environment
–
–
–
–
System Management, Autonomic Computing
Data Management and Storage Management
Knowledge Management and Collaboration
Business Computing Services
© 2004 IBM Corporation
© 2004 University of Chicago
27
Globus Toolkit® and
WS-Resource Framework
Improved robustness,
scalability, performance,
usability
3.2
2004
3.2
March
4.0 b
Q2
4.0
Q3
4.2 b
Q4
2005
4.0
WSRF; some new
functionality; further
usability, performance
4.2
enhancements
Q1 ‘05
Note: We are
not waiting for
finalization
of WSRF specs
© 2004 IBM Corporation
© 2004 University of Chicago
4.2
Numerous new WSRF-based services
28
Implications for the Globus Community
 Production deployments based on GT pre-WS
components
• These components will be included in 3.2 and 4.x,
and we will continue to support you
 Projects based on GT OGSI components
• Changes are regretted but promise ubiquity
• We will work to ease transition to WSRF
• Similarities between OGSI and WSRF imply that most
changes will be straightforward
© 2004 IBM Corporation
© 2004 University of Chicago
29
Globus Priorities for 2004
 Stabilize the infrastructure around WSRF
• Top priority!
Usability, performance, reliability, scalability,
documentation, internationalization
 Bring to fruition new functionality in pipeline
•
•
•
•
Data access & integration, metadata mgmt
Enhanced GridFTP
Community scheduling framework
Monitoring & discovery frameworks
 Expand set of solution providers
 Expand engagement with corporate space
© 2004 IBM Corporation
© 2004 University of Chicago
30
GT 3.2
(ETA March 2004)
 Many bug fixes
 Usability improvements
 New services
• OGSI-based CAS
• Registry based on OGSI
ServiceGroup
 Improved GridFTP
 Improved RFT
• Recursive copy, scalability
 Improved RLS
• Hierarchical indexing
 Improved GRAM
• Better fault tolerance,
scalability
© 2004 IBM Corporation
© 2004 University of Chicago
 OGSA Data Access &
Integration: preview
 Optimized core
• Reduced memory footprint
• Some speed improvements
 eXtensible IO (XIO)
•
•
•
•
Transforms + transport
Globus IO targets XIO
Improved performance
Multiple transports
 Security
• Java CRL support
• Anonymous authentication
• Improved performance
31
GT 4.0 Practicalities
 GT 4.0 will implement draft WSRF specs
• Based on initial standard submissions
• Rev needed for final standards  but we will work
very hard on backward compatibility
 Goal is to preserve OGSI client and service APIs as
much as possible
• No OGSI support: 4.0 WS components will not
interoperate with 3.x WS components
 All pre-WS components will still be there
• 4.0 pre-WS components will interoperate with 3.x
pre-WS components
© 2004 IBM Corporation
© 2004 University of Chicago
32
For More Information
 Specifications, architecture documents, FAQ, and
other information
• http://www.globus.org/wsrf
 Discussion forum
• http://www.ggf.org/ogsi-wg
© 2004 IBM Corporation
© 2004 University of Chicago
33
TECHNICAL
SUBJECTS AHEAD
PROCEED WITH
CAUTION !
CAUTION - Paradigm Shift
No hardheads beyond this point
© 2004 IBM Corporation
© 2004 University of Chicago
34
What is a Web Service ?
 An operation execution component made available at an endpoint
address
• A service is defined in terms of the operations it implements
• An operation is defined in terms of a message exchange
• The supported set of messages exchanges (operations)
implemented by a service may be described as a WSDL portType
(The Web service interface definition)
• The Web service itself is typically stateless
 Accessible through use of a WS-Addressing Endpoint Reference
 Lifecycle of a Web service typically described in terms of
“deployment”
 Service interface definitions often imply the existance of stateful
resources that are used and manipulated in the processing of a
Web service request message
© 2004 IBM Corporation
© 2004 University of Chicago
35
What do we mean by Stateful Resource ?

A specific set of state data expressible as an XML
document that defines the type of the resource;

Having a well-defined identity and lifecycle; and

Known to, and acted upon, by one or more Web
services.

Many possible implementations
•

Files, Database tables, EJB Entities, XML documents, Composed
from multiple data sources, etc.
Lifecycle expressed in terms of resource creation and
destruction
•
Identity is assigned at creation time
© 2004 IBM Corporation
© 2004 University of Chicago
36
WS-Addressing
 Standardizes the representation of the address of a Web service
deployed at a given network endpoint
 A WS-Addressing endpoint reference is an XML serialization of a
network-wide pointer to a Web service
 EPRs can be used to pass services to other services by
reference
 An EPR contains:
• Service address (wsa:Address)
• Metadata associated with the Web service such as service
description information
• Policy information related to the use of the service
• Reference properties, which can be used to define a contextual use
of the endpoint reference (wsa: ReferenceProperties)
© 2004 IBM Corporation
© 2004 University of Chicago
37
The WS-Resource framework model
Web Service
Run-time environment
WSDL
Interface
© 2004 IBM Corporation
© 2004 University of Chicago
Web
Service
38
The WS-Resource framework model
Invoking a Web Service
Endpoint
Reference
Run-time environment
message
© 2004 IBM Corporation
© 2004 University of Chicago
message
Interface
address
Web
Service
39
Implied Resource Pattern
 A specific kind of relationship between a Web service and a
stateful resource
 Used to associate a stateful resource with the execution of
message exchanges implemented by a Web service
 The stateful resource associated with a given message exchange
is treated as implicit execution context for the message request
 By implicit, we mean to say that the requestor does not provide
the identity of the resource as an explicit parameter in the body of
the request message
 The context used to designate the implied stateful resource is
encapsulated in the WS-Addressing endpoint reference used to
address the target Web service at its endpoint (Use of EPR
Reference Properties).
© 2004 IBM Corporation
© 2004 University of Chicago
40
WS-Resource
 When a stateful resource participates in the implied resource
pattern, we refer to it as a WS-Resource
 The wsa:Address component refers to the network transportspecific address of the Web service (often a URL in the case of
HTTP-based transports
 The wsa:ReferenceProperties component contains an XML
serialization of the WS-Resource identity, as understood by the
Web service addressed by the endpoint reference
 The WS-Resource identity represents the WS-Resource to be
used in the execution of the request message
 The set of reference properties used to hold the WS-Resource
identity within the endpoint reference is referred to as the WSResource context.
 An endpoint reference containing a WS-Resource context is a
WS-Resource-qualified endpoint reference.
© 2004 IBM Corporation
© 2004 University of Chicago
41
WS-Resource (Continued)
 The content of the WS-Resource context is opaque to the service
requestor
 The service requestor’s applications should not examine or
attempt to interpret the contents of the WS-Resource context
 The WS-Resource context is meaningful only to the Web service,
and is used by the Web service in an implementation specific way
to identify the WS-Resource needed for the execution of the
request message
 From the point of view of the service requestor:
• the WS-Resource qualified endpoint reference represents the
pointer to the Web service that has been further constrained to
execute its message exchanges within the context of a specific WSResource
• Or, the WS-Resource qualified endpoint reference represents the
pointer to a WS-Resource accessible through the message
exchanges implemented by the associated Web service
© 2004 IBM Corporation
© 2004 University of Chicago
42
The WS-Resource framework model
Using a Web service to access a WS-Resource
Endpoint
Reference
id
Resource id
Address
Run-time environment
message
© 2004 IBM Corporation
© 2004 University of Chicago
message
id
Interface
address
resource
Web
Service
contex
t
43
The WS-Resource framework model
Using a Web service to access another WS-Resource
Endpoint
Endpoint
Reference
Reference
id
Run-time environment
message
message
id
Interface
address
resource
Web
Service
resource
context
© 2004 IBM Corporation
© 2004 University of Chicago
44
WS-Resource Factory
 Any Web service capable of bringing a WS-Resource into
existence and assigning the new WS-Resource an identity
 The response message of a WS-Resource factory operation must
contain a WS-Resource-qualified endpoint reference containing a
WS-Resource context that refers to the new WS-Resource
 Note also that what we refer to here as a WS-Resource factory is
a use pattern for Web services, not a single standard operation.
This use pattern may be encoded in a variety of different Web
service operations that may, for example, create one or many
WS-Resources
© 2004 IBM Corporation
© 2004 University of Chicago
45
The WS-Resource framework model
Creating / Locating a WS-Resource
Endpoint
Reference
Run-time environment
message
Endpoint
Reference
address
© 2004 IBM Corporation
© 2004 University of Chicago
Interface
address
id
Web
Service
resource
message
46
The WS-Resource framework model
Creating / Locating another WS-Resource
Endpoint
Reference
Endpoint
Reference
Run-time environment
message
Interface
Web
Service
resource
message
Endpoint
Reference
© 2004 IBM Corporation
© 2004 University of Chicago
Interface
address
Web
Service
addres
s
transaction
id
47
The WS-Resource framework model
Passing a WS-Resource as additional context
Endpoint
Reference
Endpoint
Reference
id
Endpoint
Reference
message
Endpoint
addres
message
id
Reference
s
Web
Service
Interface
address
Register
Interface
id
context
Web
Service
Run-time environment
© 2004 IBM Corporation
© 2004 University of Chicago
resource
transaction
context
48
WS-Resource Relationship Cardinality
 A Web service can execute message exchanges against zero or
more WS-Resources of a given type
 At the type level, a WSDL 1.1 portType, defining the interface to a
Web service, can be associated with at most one type of WSResource
 One type of WS-Resource can be associated with many WSDL
1.1 portTypes
© 2004 IBM Corporation
© 2004 University of Chicago
49
WS-Resource and ACID Properties
 In the presence of a transactional unit of work, a Web service capable of
participating in the transactional protocol must abide by the rules of twophase-commit transaction management. However, in the absence of a
transaction management policy, the Web service is under no obligation
to recover the state of the WS-Resource in the event of a failure
 The WS-Resource definition is not prescriptive with respect to policy that
governs concurrent read or write access to a WS-Resource through a
Web service. The definition of specific policy governing concurrent
updates, whether or not separate message executions targeting the
same WS-Resource may be interleaved, and whether partially
completed WS-Resource updates within a given message execution
may be observed by other concurrent requests is beyond the scope of
the WS-Resource definition
 If WS-Resource isolation is needed, we suggest the use of a transaction
to provide a context within which isolation of WS-Resource updates can
be provided
 In the absence of a transactional unit of work, the level of WS-Resource
update atomicity, recovery, isolation, and durability provided by a Web
service is implementation dependent
© 2004 IBM Corporation
© 2004 University of Chicago
50
WS-Resource Security
 In the presence of a valid security context associated with a message
exchange, a Web service capable of participating in the expressed
security protocols must implement and enforce the security policies
implied by the security context
 In the absence of such security policy, the Web service is under no
obligation to secure the execution of the message exchange nor the
state of the WS-Resource designated by the WS-Resource context
associated with the message request
 The WS-Resource framework is not prescriptive with respect to policy
that governs access permission to a WS-Resource through a Web
service. The definition of specific security policy governing access to the
WS-Resource is beyond the scope of the WS-Resource definition
 If WS-Resource access control is required, we suggest the use of the
functions such as those defined in the WS-Security specifications to
provide a security context for the WS-Resource
 In the absence of a valid security context and associated access control
policies, the extent to which the Web service provides security of the
WS-Resource is implementation dependent.
© 2004 IBM Corporation
© 2004 University of Chicago
51
Why Refer To A Resource In This Way?
 Q: If you want to give me a resource reference to
which I can direct messages, what exactly do you
give me? Options include:
• URL = service address and resource identifier.
But URL syntax is too restrictive and fragile.
Must define how resource identifier flows on message.
• URI = resource identifier.
But requires a global lookup service to get address.
Must define how resource identifier flows on message.
• Resource identifier + service address.
This is exactly what an EndpointReference is.
Defines how resource identifier flows on message.
But must define how service address can change.
 This is the approach taken by WS-Coordination
© 2004 IBM Corporation
© 2004 University of Chicago
52
Relationship to WS-Context (WS-CAF)
 WSRF and WS-Context are largely orthogonal
• WSRF uses WS-Addressing to refer to a resource,
and defines basic resource inspection, lifetime, etc.
• WS-Context defines approach to flowing a context on
messages to multiple services, perhaps including a
identifier to a context managed by a context service.
 They can (at least) peacefully co-exist, and could
probably we made to be even more complimentary
• E.g. Context identifier could be a WS-Resource
• E.g. Context service could use WS-ResourceLifetime
 WS-Context is in an OASIS technical committee
• But IBM, Microsoft, and BEA not participating
© 2004 IBM Corporation
© 2004 University of Chicago
53
WS-ResourceProperties
 Operations and meta data associated with elements of a
resource’s state
 Resource Properties document
• Presented via Web service as an XML document
<GenericDiskDriveProperties xmlns:tns="http://example.com/diskDrive" >
<tns:NumberOfBlocks>22</tns:NumberOfBlocks>
<tns:BlockSize>1024</tns:BlockSize>
<tns:Manufacturer>DrivesRUs</tns:Manufacturer>
</GenericDiskDriveProperties>
• Modelled using standard XML Schema
 PortType declares association between Web service and
resource properties document
• Information is available at design time, as part of the interface
• Use xsd:ref to mix in resource properties from multiple
interfaces
© 2004 IBM Corporation
© 2004 University of Chicago
54
WS-ResourceProperties
 Resource Properties operations
 Get
<wsrp:GetResourcePropertyRequest>
QName
</wsrp:GetResourcePropertyRequest>
 Get Multiple
 Query
<wsrp:GetMultipleResourcePropertiesRequest>
QName *
</wsrp:GetMultipleResourcePropertiesRequest>
<wsrp:QueryResourcePropertiesRequest>
<wsrp:QueryExpression dialect=”URI”>
xsd:any
</wsrp:QueryExpression>
</wsrp:QueryResourcePropertiesRequest>
© 2004 IBM Corporation
© 2004 University of Chicago
55
WS-ResourceProperties
 Resource Properties operations (con’t)
 Set
<wsrp:SetResourcePropertiesRequest>
{
<wsrp:Insert >
xsd:any
</wsrp:Insert> |
<wsrp:Update ResourceProperty=”QName”>
xsd:any
</wsrp:Update> |
<wsrp:Delete ResourceProperty=”QName” />
}+
</wsrp:SetResourcePropertiesRequest>
© 2004 IBM Corporation
© 2004 University of Chicago
56
WS-ResourceLifetime
 Immediate Destruction
<wsrl:DestroyRequest />
 Scheduled Destruction
<wsrl:SetTerminationTimeRequest>
<wsrl:RequestedTerminationTime>
xsd:dateTime
</wsrl:RequestedTerminationTime>
</wsrl:SetTerminationTimeRequest>
 Resource Properties
• Current Time
• Termination Time
 Initial Termination Time
© 2004 IBM Corporation
© 2004 University of Chicago
57
WS-ResourceLifetime
 Resource Destruction Notification
<wsnt:topicSpace name="ResourceLifetime"
targetNamespace=
"http://www.ibm.com/xmlns/stdwip/web-services/WS-ResourceLifetime"
…>
<wsnt:topic name="ResourceTermination">
 Suggested Contents
<wsrl:TerminationNotification>
<wsrl:TerminationTime>xsd:dateTime</wsrl:TerminationTime>
<wsrl:TerminationReason>xsd:any</wsrl:TerminationReason>?
</wsrl:TerminationNotification>
© 2004 IBM Corporation
© 2004 University of Chicago
58
WS-Notification
 WS-Notification
• Brings enterprise quality publish and subscribe
messaging to Web services
– Loosely coupled, asynchronous messaging in a Web
services context
• WS Notification exploit WS Resource framework
and Web services technologies
• Direct and Brokered notification
• Topics and Topic Spaces
• More on subscribe
• Other WS-Notification concepts
© 2004 IBM Corporation
© 2004 University of Chicago
59
WS-Notification
 Direct notification: Three primary roles
Subscriber
 Subscriber deals directly with the
producer of the Notifications
subscribe
• indicates interest in a particular
“Topic” by issuing a “subscribe”
request
 An EPR to the subscription is
returned
Consumer
 Producer is responsible for
detecting situation and
creating the notification
 Subscriptions that match
receive the notification
Producer
subscribe
notify
EPR
S
© 2004 IBM Corporation
© 2004 University of Chicago
60
WS-Notification
 Subscriber indicates interest in a particular
“Topic” by issuing a “subscribe” request
Subscriber
subscribe
 Broker (intermediary) permits
decoupling Publisher and Subscriber
notify
 “Subscriptions” are WS-Resources
• Various subscriptions are possible
Broker
 Publisher need NOT be a Web Service
notify
notify
subscribe
 Notification may be “triggered” by:
• WS Resource Property value changes
• Other “situations”
 Broker examines current subscriptions
 Brokers may
S
S
S
Publisher
notify
• “Transform” or “interpret” topics
• Federate to provide scalability
© 2004 IBM Corporation
© 2004 University of Chicago
61
WS-Notification
 More on Subscribe Request
<wsnt:SubscribeRequest>
<wsnt:ConsumerReference>EPR </wsnt: ConsumerReference>
<wsnt:TopicPathExpression />
<wsnt:UseNotify> xsd:boolean </wsnt:UseNotify>?
<wsnt:Precondition> wsrp:QueryExpression </Precondition>?
<wsnt:Selector> wsrp:QueryExpression </wsnt:Selector>?
<wsnt:SubscriptionPolicy> wsp:Policy </wsnt:SubscriptionPolicy>?
<wsrl:InitialTerminationTime> xsd:dateTime</wsrl:InitialTerminationTime>?
</wsnt: SubscribeRequest>
 Returns EPR to a Subscription WS-Resource
© 2004 IBM Corporation
© 2004 University of Chicago
62
WS-Notification
 Topics and Topic Spaces
• Meta-data to help
– Organize Notifications
– Tell the Subscriber what to subscribe to
<?xml version="1.0" encoding="UTF-8"?>
<wsnt:topicSpace name="TopicSpaceExample1"
targetNamespace="http://example.org/topicSpace/example1"
…>
<wsnt:topic name="t1">
<wsnt:topic name="t2" messageTypes="tns:m1 tns:m2"/>
<wsnt:topic name="t3" messageTypes="tns:m3"/>
</wsnt:topic>
<wsnt:topic name="t4">
<wsnt:topic name="t5" messageTypes="tns:m3"/>
<wsnt:topic name="t6" aliasRef="tns:t1/t3"/>
</wsnt:topic>
</wsnt:topicSpace>
© 2004 IBM Corporation
© 2004 University of Chicago
63
WS-ResourceProperties Subscription
 Subscription for Value Change
 Rules for mapping resource properties to Topics
• QName of resource property corresponds QName of Topic
 To subscribe to changes in tns:NumberOfBlocks:
<wsnt:SubscribeRequest>
<wsnt:ConsumerReference>…
<wsnt:TopicPathExpression >
tns:NumberOfBlocks
<wsnt:TopicPathExpression>
…
</wsnt: SubscribeRequest>
 Suggested format of value change message
© 2004 IBM Corporation
© 2004 University of Chicago
64
Completing the WS-ResourceFramework
 WS-ServiceGroup
• A Web service that maintains information about a
group of other Web services or WS-Resources.
• Services may be members of a group for a specific
reason, such as being part of a federated service
or
• they may have no specific relationship, such as the
services contained in an index or registry operated
for discovery purposes.
© 2004 IBM Corporation
© 2004 University of Chicago
65
Completing the WS-ResourceFramework
© 2004 IBM Corporation
© 2004 University of Chicago
66
Completing the WS-ResourceFramework
 WS-RenewableReferences
• Adjunct to the WS-Addressing specification
• Brings enterprise quality to Endpoint References
• Not a general purpose service naming capability
• Multiple, optional ReferenceResolver EPRs
– Uses WS-Policy element of the EPR to hold
ReferenceResolver EPRs
– Allows transparency to the client programming
model by hiding resolution function in the reference
proxy
• “Handle” is encoded as reference properties of the
ReferenceResolver EPR
• Renewal request includes original EPR as
parameter
© 2004 IBM Corporation
© 2004 University of Chicago
67
Completing the WS-ResourceFramework
<wsa:EndpointReference>
<wsa:Address>xs:anyURI</wsa:Address>
<wsa:ReferenceProperties/>
<wsa:PortType>xs:QName</wsa:PortType> ?
<wsp:Policy>
<wsrr:Renewable>
<wsrr:ReferenceResolver>
wsa:EndpointReference
</wsrr:ReferenceResolver>
<wsrr:Renewable>
</wsp:Policy>
</wsa:EndpointReference>
© 2004 IBM Corporation
© 2004 University of Chicago
68
Completing the WS-ResourceFramework
 Endpoint References provide
• A reference to the WS-Resource
• A mechanism for renewing that reference
• A collection of alternative addresses for a WSResource
In other words an endpoint reference logically
becomes the Locator
© 2004 IBM Corporation
© 2004 University of Chicago
69
Completing the WS-ResourceFramework
 WS-BaseFaults
• Similar to OGSi v1.0 common fault definition
• Add structure to WSDL error messages
• Define mapping to SOAP 1.2 faults
© 2004 IBM Corporation
© 2004 University of Chicago
70