WS-Resource Framework

1
WS-Resource Framework

• Adam Belloum
• Computer Architecture Parallel Systems group
• University of Amsterdam
• adam_at_science.uva.nl

2
Grid and Web Services Convergence?
Grid
Web
However, despite enthusiasm for OGSI, adoption
within Web community turned out to be problematic
WS-Resource Framework Globus Alliance
Perspectives I. Foster
3
Grid and Web ServicesConvergence Yes!
Grid
Web
The definition of WSRF means that Grid and Web
communities can move forward on a common base
WS-Resource Framework Globus Alliance
Perspectives I. Foster
4
Web Service and State

• Web service interfaces frequently provide a user
  with the ability to access and manipulate state
• Message exchanges that Web services implement are
  frequently intended to enable access to stateful
  resources.
• However, the notion of stateful resources acted
  upon by the Web service implementation is not
  explicit in the interface definition.

5
Web Service and State

• It is desirable to define Web service conventions
  to enable
• the discovery of, introspection on, and
  interaction with stateful resources in standard
  and interoperable ways.
• WS-Resource is approach to modeling state in a
  Web services context

6
Web Service and State

• A WS-Resource is defined as the composition of a
  Web service and a S-Resource
• Expressed as an association of an XML document
  with defined type with a Web services portType
• Addressed and accessed according to the implied
  resource pattern,
• a conventional use of WS-Addressing endpoint
  references
• In the implied resource pattern, a S-Resource
  identifier is encapsulated in an endpoint
  reference
• to identify the S-Resource to be used in the
  execution of a Web service message exchange.

7
WS-Resource Framework

• WS-Resource framework allows WS-Resources to be
• declared, created, accessed, monitored for
  change, and destroyed via conventional Web
  services mechanisms,
• but
• does not require that the WS component of the
  WS-Resource to be implemented as a stateful
  message processor.

8
WS-Resource Framework

• WS-Resource framework, is a set of five technical
  specifications define in terms of
• specific WS message exchanges
• and related XML definitions.
• The specifications allow
• WS-Resource to be destroyed,
• Type definition of a WS-Resource can be composed
  from the interface of a WS endpoint reference
• Heterogeneous by-reference collections of Web
  services can be defined
• Fault reporting can be made more standardized
  through use of an XML Schema

9
The five specification composing the WSRF
10
How these proposals relates to other Web services
standards
Service Composition
BPEL4WS
WS-Service Group
WS-Notification
Quality of Experience (QoX)
WS-Reliable Messaging
WS-Transaction
WS-Security
WS-Resource Lifetime
Description
WS-Base Faults
WS-Resource Properties
XSD
WSDL
WS-Metadata Exchange
WS-Policy
Messaging
SOAP
XML
WS-Addressing
WS-Renewable References
Transports
JMS
SMTP
RMI / IIOP
HTTP/HTTPS
11
Renewable References

• The WS-RenewableReferences work defines
  mechanisms that can be used to renew an endpoint
  reference that has become invalid.
• These mechanisms can be applied to any endpoint
  reference, but are particularly useful
• For endpoint reference that refers to a
  WS-Resource,
• as it can provide a persistent and stable
  reference to the WS-Resource that can allow the
  same state to be accessed repeatedly over time.

12
Renewable References

• A WS-Addressing endpoint reference may contain
• not only addressing
• policy information concerning interactions with
  the service.
• Typically, endpoint references are constructed by
  an authoritative source of the addressing and
  policy information.
• An endpoint reference made available to a client
  represents a copy of that information
• at some point, become incoherent due to changes
  introduced by the authoritative source that
  effects the endpoint location and/or the policy

13
Service Groups

• The WS-ServiceGroup specification defines a means
  of representing and managing heterogeneous
  by-reference collections of Web services.
• organize collections of WS-Resources, for example
  to build registries
• build services that can perform collective
  operations on a collection of WS-Resources.

14
Service Groups

• The ServiceGroup specification express
  ServiceGroup
• membership rules,
• Membership constraints
• classifications.
• Groups can be defined.

• using the resource property model from
  WS-ResourceProperties
• as a collection of members that meet the
  constraints of the group as expressed through
  resource properties

15
Base Faults

• The WS-BaseFaults specification defines a base
  fault type for use when returning faults in a Web
  services message exchange.
• Used by all of the other WS-Resource framework
  specifications to bring consistency to the faults
  returned by the operations including
• consistent reporting of faults relating to
  WS-Resource definition and use.

16
Notification

• WS-Notification, defines a general, topic based
  WS system for (pub/sub) interactions that builds
  on the WS-Resource framework.
• From the perspective of WS-Notification
• WS-Resource framework provides useful building
  blocks for representing and structuring
  notifications.
• From the perspective of the WS-Resource
  framework,
• WS-Notification specifications extends
  WS-Resources by allowing requestors to ask to be
  asynchronously notified of changes to resource
  property value

17
Modeling Stateful Resources with Web Services
18
Possible association between State and Services

• A stateless service implements
• message exchanges with no access or use of
  information not contained in the input message
• A conversational service implements
• a series of operations such that the result of
  one operation depends on a prior operation and/or
  prepares for a subsequent operation
• A service that acts upon stateful resources
• access to, or manipulates a set of logical
  stateful resources based on messages it sends and
  receives.

19
Stateless Implementations, Stateful Interfaces

• A Service that acts upon stateful resources may
  be described stateless
• if it delegates responsibility for the management
  of the state to another component.
• The service is responsible for the state of the
  resource between message exchanges

20
A consequence of statelessness

• Any dynamic state needed for a given
  message-exchange execution must be
• provided explicitly within the request message,
  whether
• directly by-value
• indirectly by-reference maintained implicitly
  within other system components with which the WS
  can interact.

21
Modeling State in Web Services (WS-Resource)

• WS-Resource is composed of a Web service and a
  S-Resource
• S-Resource is used in the execution of Web
  service message exchanges
• WS-Resources can be created and destroyed
• S-Resource is associated with the interface of a
  WS to enable well-formed queries against the
  state of a WS-Resource

22
Modeling State Stateful Resources

• A S-Resource is defined as having
• specific set of state data expressible in XML
  format
• a well-defined lifecycle known to, and acted
  upon, by one or more Web services.

23
How stateful resource is referred to by Web
services?

• The implied resource pattern refers to the
  mechanisms used to associate
• a S-Resource
• with the execution of message exchanges
  implemented by a Web Service.

24
The Implied Resource Pattern

• Implied is used because the S-Resource associated
  with a message exchange is treated as implicit
  input for the execution of the message request.
• The Association of WS and S-Resource is either
  static or a dynamic.
• Static if the association is made when the WS is
  deployed.
• Dynamic if the association is made at time of
  message exchange (S-Resource is encapsulated in
  the WS-Addressing endpoint reference).
• Pattern indicates that the relationship between
  WS and S-resources is
• codified by a set of conventions on existing WS
  technologies, in particular XML, WSDL, and
  WS-Addressing.

25
WS-Addressing

• WS-Addressing standardizes
• The endpoint reference used to represent the
  address of a WS.
• endpoint contain metadata associated with the WS
• service description information
• reference properties
• A WS-Addressing endpoint reference is an XML
  serialization of a network-wide pointer to a WS

26
WS-Resource and WS-Addressing

• SW (2) returns an Endpoint reference to the
  requestor
• C is S-resource created
• SW (2) represents an explicit WS-Resource
  factory.
• The endpoint reference (3) contains
• WsaAddress (4)
• refers to the network transport-specific address
  of the WS (URL).
• same address that would appear within a port
  element in a WSDL of the WS
• wsaReferencePropertie
• contain an XML serialization of a S-Resource
  identifier.

27
WS-Resource and WS-Addressing

• S-Resource identifier
• is meaningful only to the SW,
• used by the WS in an implementation-specific to
  identify the WS-Resource related S-Resource
  needed for the execution.
• should not be examined or interpreted by the
  service requestors applications
• Is represented using a service-specific XML
  element by XML serialization of the S-Resource

28
WS-Resource and WS-Addressing

• S-Resource identifier
• must identify a unique S-Resource to be used the
  execution of the request message.
• the scope of the S-Resource identifier must be
  unique within the scope of the WS.
• multiple identifiers within the scope of a WS may
  refer to the same WS-Resource.

29
WS-Resource-qualified endpoint reference

• the endpoint reference represents a pointer to
  the WS-Resource
• service requestor
• must understand that the endpoint reference
  refers to a WS-Resource.
• must recognize that the endpoint reference is a
  WS-Resource qualified endpoint reference.

30
WS-Resource-qualified endpoint reference

• requestor use the endpoint reference (1) to send
  messages (2) to the identified SW(3)
• WS-Resources endpoint reference contains a
  S-Resource identifier in its ReferenceProperties
• request message directed to the WS using that
  endpoint reference must include the S-Resource
  identifier.

31
WS-Resource Relationship Cardinality

• A WS can execute message exchanges against
• zero
• more S-Resources defined as instances of the
  resource property document.
• A single WS at a particular endpoint is
  associated with several individual S-Resources

32
WS-Resource Relationship Cardinality (At the type
level)

• WSDL 1.1 portType, defining the interface to a
  WS
• can be associated with at most one S-Resource
  property document.
• S-Resource property document can be associated
  with many portTypes.
• Any WS that implements a portType is by
  definition a WS associated with a S-Resource

33
WS-Resource Relationship Cardinality

• At the instance level, a S-Resource can be
  associated with one or more WS.
• The one-to-many relationship between a S-Resource
  instance and a WS is exploited to
• allow multiple network protocol or network
  endpoints to process messages for the
  WS-Resource,
• allow different WS interfaces to categorize and
  subset messages that act upon the S-Resource.

34
WS-Resource Encapsulation

• Strict encapsulation guarantees that encapsulated
  data can only be accessed through well defined
  operations.
• Data encapsulation facilitates the use of data
  without the user having to understand the details
  of the data implementation
• The implied resource pattern facilitates varying
  degrees of WS encapsulation of S-Resources.

35
WS-Resource Lifecycle

• The lifetime of a WS-Resource is defined as
  the period between its creation and its
  destruction.
• WS-Resource creation using a WS-Resource factory
• Assignment use of the S-Resource identifier
• destruction of a WS-Resource.

36
WS-Resource Creation

• WS-Resource factory is any WS capable of creating
  a WS-Resource
• creating a new S-Resource
• assigning the new S-Resource an identity,
• associating the new S-Resource and its WS.
• The response message of a WS-Resource factory
  operation contains
• WS-Resource-qualified endpoint reference
  containing a S-Resource identifier that refers to
  the new S-Resource

37
WS-Resource Identity

• We describe and contrast the role and use of
  WS-Resource identity from two perspectives
• From the private perspective of the WS-Resource
  implementation
• From the public perspective of a service
  requestor to whom an endpoint reference to a
  WS-Resource is provided.

38
WS-Resource Identity

• S-Resource has at least one form of identity that
  identifies S-Resource component within the
  WS-Resource composition.
• To a WS with a S-Resource is associated
• the S-Resource identifier carried within a
  request message is meaningful.

39
WS-Resource Identity

• A service requestor that obtains access to a
  WS-Resource-qualified endpoint reference
• should not examine or attempt to interpret the
  value of the S-Resource identifier.
• even comparing the contents of two S-Resource
  identifiers is considered invalid.
• From the perspective of the service requestor,
  the content of the S-Resource identifier within
  the endpoint reference is opaque.

40
WS-Resource Identity

• How would a service requestor reason about the
  public identity of a S-Resource of a WS-Resource?
  
• Answer the semantic meaning of the S-Resource
  identity, and the means by which it is defined
  and exposed to requestor, is WS implementation
  dependent.
• The identity should be a portable,
  namespace-scoped value

41
WS-Resource Destruction

• A requestor that wishes to terminate a
  WS-Resource uses WS-Resource-qualified endpoint
  reference to
• Immediate Destruction send a destroy request
  message to the WS using by the endpoint
  reference.
• Scheduled Destruction message exchanges for
  establishing and renewing scheduled destruction
  times on WS-Resources

42
WS-Resource Properties

• WS-Resource has an XML resource property
  document defined using XML schema.
• Requestors determine a WS-Resources type by
  retrieving the WSDL portType definition.
• Requestors use WS message exchanges to read,
  modify, and query the XML document representing
  the WS-Resources state.

43
WS-Resource Properties

• resource property to refer to
• An individual component of a WS-Resources state.
  
• XML document describing the type of a S-Resource
  within the WS-Resource is a WS-Resource
  properties document.
• Each resource property is represented as an XML
  element within the WS-Resource properties document

44
WS-Resource Properties Document

• WS-Resource properties document acts as a view
  on, or projection of, the actual state of the
  WS-Resource.
• the structure upon which requestor-initiated
  queries and updates can be directed.
• Any operation that manipulates a resource
  property via the WS-Resource properties document
  must be reflected in the actual implementation of
  the WS-Resources state.

45
WS-Resource Properties Document

• the state of C comprises 3 components, p1, p2,
  and p3
• resource properties document, ExampleResourceProp
  erties,.

46
WS-Resource Properties Document

• WS-Resource properties document declaration is
  associated with the WSDL portType using a
  standard attribute, resourceProperties

47
WS-Resource Property Composition

• Web services allow to construct a new interface
  from several existing interfaces via a process of
  composition
• In WSDL 1.1, this composition must be achieved by
  a copy-and-paste of the operations defined in the
  constituent portTypes used in the composition

48
WS-Resource Property Composition

• aggregation of WS-Resource properties of the
  various constituent portTypes is also possible.
• WS-Resource properties document composition is
  obtained by adding additional XML element
  declarations, using
• xsref attribute

49
Accessing WS-Resource Property Values

• The values of resource properties exposed in the
  WS-Resources resource properties document, can
  be
• read, modified, and queried by using standard WS
  messages.
• The base functionality is to retrieve the value
  of a single resource property using a simple WS
  message exchange

50
Accessing WS-Resource Property Values

• Retrieval function allow the retrieval of
  multiple resource properties with a single
  message exchange.
• The WS responds with a message containing the
  values of the requested WS-Resource properties
• message exchange to execute an arbitrary Xpath
  expression against the resource properties
  document.
• query expression types may be used to support
  resource discovery based on the values of a
  WS-Resources state.

51
WS-Resource and ACID Properties

• Atomicity requires that the updates to
  S-Resources used within the context of a
  transaction be made in all or nothing fashion.
• Consistency refers to the ability of a
  transaction to leave resources in a consistent
  state.
• Isolation ensures that partial updates to
  S-Resources used within the transaction are not
  visible outside until its end.
• Durability provides for the permanence of
  S-Resource updates made under the transaction.

52
WS-Resource and ACID Properties

• The ability to associate a transactional recovery
  policy to the execution of a WS message exchange
• In the presence of a transactional unit of work,
  a WS capable of participating in the
  transactional protocol must abide by the rules of
  two-phase-commit transaction management.
• In the absence of a transaction management
  policy, the WS is under no obligation to recover
  the state of the WS-Resource in the event of a
  failure.

53
WS-Resource and ACID Properties

• If WS-Resource isolation is needed,
• use of a transaction to provide a context within
  which isolation of updates can be provided.
• In the absence of a transactional unit of work,
  the level of update ACID provided by a WS is
  implementation dependent.
• the ability to declare and attach isolation-level
  policy to the definition of a WS message
  exchange, whether or not a transactional unit of
  work, represents a general requirement not met by
  the current Web service architecture.

54

• Association of security policy to WS
• described in the WS-Policy and WS-SecurityPolicy
  specifications which are part of the WS Security
  Roadmap..
• In the presence of a valid security context
  associated with a message exchange,
• WS capable of participating in the security
  protocols must implement and enforce the security
  policies.
• In the absence of a security policy,
• the WS is under no obligation to secure the
  execution of the message exchange nor the state
  of the WS-Resource.

55
WS-Resource Security

• The WS-Resource definition is not prescriptive
  with respect to policy that governs access
  permission to a WS-Resource.
• The definition of specific security policy
  governing access to the WS-Resource is beyond the
  scope of the WS-Resource Framework.
• If WS-Resource access control is required, we
  suggest the use of the functions 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 WS provides security of the WSResource
  is implementation dependent