The Cover PagesThe OASIS Cover Pages: The Online Resource for Markup Language Technologies
SEARCH | ABOUT | INDEX | NEWS | CORE STANDARDS | TECHNOLOGY REPORTS | EVENTS | LIBRARY
SEARCH
Advanced Search
ABOUT
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors

NEWS
Cover Stories
Articles & Papers
Press Releases

CORE STANDARDS
XML
SGML
Schemas
XSL/XSLT/XPath
XLink
XML Query
CSS
SVG

TECHNOLOGY REPORTS
XML Applications
General Apps
Government Apps
Academic Apps

EVENTS
LIBRARY
Introductions
FAQs
Bibliography
Technology and Society
Semantics
Tech Topics
Software
Related Standards
Historic
Created: March 10, 2004.
News: Cover StoriesPrevious News ItemNext News Item

OASIS Forms TCs for Web Services Resource Framework and Web Services Notification.

Update 2004-03-31: "Web Services Resource Framework Adds WS-BaseFaults and WS-ServiceGroup."

Technical work on the refactoring of Open Grid Services Infrastructure (OGSI) Version 1.0 has been brought to OASIS with the formation of two new technical committees: the Web Services Resource Framework (WSRF) TC and Web Services Notification (WSN) TC.

The WSRF TC will "define a generic and open framework for modeling and accessing stateful resources using Web services. This includes mechanisms to describe views on the state, to support management of the state through properties associated with the Web service, and to describe how these mechanisms are extensible to groups of Web services. The TC's goal is to define a set of royalty-free, related, interoperable and modular specifications that will allow the relationship between a Web service and state to be modelled in an explicit and standardized fashion." The WSRF TC will revise the recently re-published WS-ResourceProperties and WS-ResourceLifetime specifications; it will also release new specifications for the three other principal modules of the OGSI-TNG Web Services Resource Framework: WS-RenewableReferences, WS-ServiceGroup, and WS-BaseFaults.

The Web Services Notification TC has been chartered to "define a set of specifications that standardise the way Web services interact using the Notification pattern. In the Notification pattern a Web service, or other entity, disseminates information to a set of other Web services, without having to have prior knowledge of these other Web Services." The OASIS WSN TC will develop a revised set of WS-Notification Framework specifications (WS-Base Notification, WS-Topics, WS-Brokered Notification) and will publish a WS-NotificationPolicy specification detailing the policy language associated with Notification.

From the WS-Resource Framework Overview Document

"The WS-Resource construct has been proposed as a means of expressing the relationship between stateful resources and Web services. We introduce here the WS-Resource framework, a set of proposed Web services specifications that define a rendering of the WS-Resource approach in terms of specific message exchanges and related XML definitions. These specifications allow the programmer to declare and implement the association between a Web service and one or more stateful resources. They describe the means by which a view of the state of the resource is defined and associated with a Web services description, forming the overall type definition of a WS-Resource. They also describe how the state of a WS-Resource is made accessible through a Web service interface, and define related mechanisms concerned with WS-Resource grouping and addressing. This paper provides an architectural overview of the WS-Resource framework. It motivates, introduces, and summarizes the interrelationships among five separate specification documents that provide the normative definition of the framework: WS-ResourceProperties, WSResourceLifetime, WS-RenewableReferences, WS-ServiceGroup, and WS-BaseFaults. We also describe how the WS-Resource framework can support the WS-Notification family of specifications for asynchronous notification." [from the document abstract]

Details from the OASIS Web Services Resource Framework (WSRF) TC Proposal

WSRF TC Statement of Purpose

The purpose of the Web Services Resource Framework (WSRF) TC is to define a generic and open framework for modeling and accessing stateful resources using Web services. This includes mechanisms to describe views on the state, to support management of the state through properties associated with the Web service, and to describe how these mechanisms are extensible to groups of Web services.

Web services implementations are often stateless in that they maintain no dynamic state whose lifetime exceeds the processing of an individual message. The statelessness of Web service implementations is a valuable asset to their availability and ability to accommodate dynamic workloads.

Web service interfaces, on the other hand, often imply the need for some form of stateful interaction with the clients of the service. This may be manifest in a conversational style of use of a particular Web service interface in which some aspect of the result of one operation influences the execution of the next operation. The state in interactions with such interfaces is typically contained in or referred to from the messages that are exchanged with the target service. Inferences concerning the nature of the state may sometimes be made, but only in an application-specific fashion and not in a generic manner that can be exploited easily by tooling.

The goal of this TC is to define a set of royalty-free, related, interoperable and modular specifications that will allow the relationship between a Web service and state to be modelled in an explicit and standardized fashion. This will simplify the definition of new service interfaces and enable more powerful discovery, management and development tools. These specifications will be composable with other available Web services specifications enabling applications to access state with the qualities of service - for example security, transactions and reliability - provided for in those specifications.

WSRF TC Scope of Work

The scope of this work is to define a framework within which Web services can access state in a consistent and interoperable manner, and an access pattern through which service requesters can interact indirectly with stateful resources through a Web service that encapsulates the state. An architectural separation will be maintained between a stateful resource and the Web service that encapsulates it to promote the desirable loose coupling between service requestor and the stateless service provider and to provide a highly available and scalable means to interact with state.

This TC will define the means by which:

  • Web services can be associated with one or more stateful resources (named, typed, state components).
  • Service requestors access stateful resources indirectly through Web services that encapsulate the state and manage all aspects of Web service based access to the state.
  • Stateful resources can be destroyed, through immediate or time based destruction.
  • The type definition of a stateful resource can be associated with the interface description of a Web service to enable well-formed queries against the resource via its Web service interface.
  • The state of the stateful resource can be queried and modified via Web service message exchanges.
  • Endpoint references to Web services that encapsulate stateful resources can be renewed when they become invalid, for example due to a transient failure in the network.
  • Stateful resources can be aggregated for domain-specific purposes.

WSDL is an essential element of Web services architecture. The specifications produced by this TC will provide WSDL definitions for all normative message exchanges.

The benefits and results of this work will be a standard way for web services to access state leading to greater simplification in the definition of new Web service interfaces, better service interoperability and greater opportunity for tools vendors to provide means to manage Web service applications and resources.

Out of Scope for WSRF TC

The following topics are outside the scope of this TC:

  • Quality of service related policy enforcement on resource property access. The TC will not address security or transactions implications in the specifications it delivers.
  • The consideration of protocol-specific bindings.
  • Query and update of WS-Resource properties is within the scope of the TC, but general purpose XML document query and update, outside the context of managing stateful resources with Web services, is out of scope.
  • A normative factory pattern for the creation of WS-Resources.

WSRF TC List of Deliverables

  • A revised WS-ResourceProperties specification. Committee Draft due within one year of the first meeting.
  • A revised WS-ResourceLifetime specification. Committee Draft due within one year of the first meeting.
  • A WS-RenewableReferences specification, which defines a conventional decoration of a Web service endpoint reference with information needed to retrieve an updated version of an endpoint reference when it becomes invalid. Committee Draft due within one year of the first meeting.
  • A WS-ServiceGroup specification, which defines an interface to heterogeneous by-reference collections of Web services. Committee Draft due within one year of the first meeting.
  • A WS-BaseFaults specification, which defines a base fault XML type for use when returning faults in a Web services message exchange. Committee Draft due within one year of the first meeting.

These specifications will reflect refinements and changes made to, and by, contributions to the TC that are identified by members for additional functionality and semantic clarity within the scope of the TC charter. The titles and granularity of the specifications may change.

Anticipated Audience for WSRF TC Deliverables

The anticipated audience for this work includes:

  • other specification writers that need stateful interaction patterns for Web services
  • vendors offering web service products
  • software architects and programmers who design and write distributed applications requiring the management of state

Identification of Existing Activities

A number of efforts that use or require state-access patterns in Web services are underway throughout the industry. The following work may be relevant to this Web Services Resource Framework TC:

WSRF TC Proposers

The following eligible people are in support of this proposal:

Details from the OASIS Web Services Notification (WSN) TC Proposal

The purpose of the Web Services Notification (WSN) TC is to define a set of specifications that standardise the way Web services interact using the Notification pattern.

In the Notification pattern a Web service, or other entity, disseminates information to a set of other Web services, without having to have prior knowledge of these other Web Services. Characteristics of this pattern include:

  1. The Web services that wish to consume information are registered with the Web service that is capable of distributing it. As part of this registration process they may provide some indication of the nature of the information that they wish to receive.

  2. The distributing Web service disseminates information by sending one-way messages to the Web services that are registered to receive it. It is possible that more than one Web service is registered to consume the same information. In such cases, each Web service that is registered receives a separate copy of the information.

  3. The distributing Web service may send any number of messages to each registered Web service; it is not limited to sending just a single message.

The Notification pattern has many applications, for example in the arenas of system or device management, or in commercial applications such as electronic trading.

The goal of this TC is to define a set of royalty-free, related, interoperable and modular specifications that allow this pattern to be modeled in an explicit and standardized fashion. The benefits of such standardization include interoperation between application entities written by different authors, as well as interoperation between different publish/subscribe messaging middleware providers.

WSN TC Scope of Work

The scope of this work is to define a set of related, interoperable and modular specifications that standardize the concepts, message exchanges, WSDL and XML schema renderings required to express the Notification pattern, as outlined in the previous section.

These specifications will cover the basic Notification pattern along with additional functions that support the use of this pattern. The items to be specified include:

  • The means by which one Web service can be registered with another in order to receive notifications. It will be possible for this registration to be performed by a third party. This includes the means by which the registration indicates the kind of information that it covers.
  • The means by which such registrations (subscriptions) can be modified or deleted.
  • The means by which a Web service delivers information to those Web services that are registered with it. This includes the possibility of "bulk notification", i.e., batching multiple pieces of information into a single message.
  • The means by which a Web service can limit the amount of information that is being sent to it.
  • The means by which a Web service can act as a "notification broker". A notification broker can act as a intermediary between the producer of the information and the Web services that receive it.
  • The means by which an entity which is not itself a Web service can use a notification broker to deliver information to Web services.
  • A language that can be used to describe a Topic information space, and associated metadata. Topics are used to categorize the kinds of information that can be sent or subscribed to as part of a subscription registration.
  • One or more Topic Expression dialects, used to identify Topics or sets of Topics, within a Topic information space.
  • The means by which a Web service can provide runtime metadata showing what Topics it has available for subscription, and in what formats the subscription can be made.
  • One or more Policy language(s) that express the policies that can be applied to a subscription (for example maximum message rate or quality of service) and to other roles and components within the scope of work of the TC.
  • A list of the various roles that Web services, or other entities, can assume within the Notification pattern, along with a description of the function required in order to fulfill each role.
  • Concepts and Terminology to support the above.

The specifications produced by the TC will be independent of binding-level details. The method of registering for information, and the actual delivery of that information will be orthogonal to transport protocols, so that the specifications can be used over a variety of different transports.

The specifications will be factored in a way that allows resource-constrained devices to participate in the Notification pattern. Such devices will be able to send information to, and receive information from Web services, without having to implement all the features of the specifications.

The specifications will be designed so that implementations of the specifications can map naturally onto traditional Messaging Middleware systems. The specifications will not describe or attempt to standardize the nature of this mapping.

The WSN TC takes, as its starting point, the Web Service Notification specification documents recently published by Akamai Technologies, Computer Associates International, Fujitsu Laboratories of Europe, the Globus Alliance/Argonne National Laboratory, Hewlett-Packard, IBM, SAP AG, Sonic Software, and Tibco Software...

The TC will coordinate with the proposed WSRF TC, and the standards produced by the WSN TC will conform to the implied resource pattern specified by the WSRF TC. Specifications produced by the WSN TC will make use of specifications from the WSRF TC concerning lifetime and properties of WS-Resources.

Out of Scope for WSN TC

The following topics are outside the scope of this TC:

  1. The TC will not prescribe any particular format for the information transmitted in a Notification (other than requiring it to be expressible as a WSDL message).
  2. The TC will not define schemas for notification messages for use in particular application domains.
  3. The TC will not define standard Topic information spaces.
  4. The TC will not define the mapping to any particular programming language, or to any particular messaging middleware.
  5. The TC will not attempt to provide specifications for things which have a wider applicability within Web Services. For example, the TC will not provide specifications for the following features:
    • Routing
    • Addressing
    • Policy Framework
    • Resource destruction
    • Resource properties
    • Reliable Messaging
    • Encryption
    • Message Integrity
    • Mechanisms to protect against corruption of an individual message
    • Authentication
    • Message Non-Repudiation
    • Transactions and Compensation

Where required, these features are provided by composing Notification with other Web Services standards.

WSN TC List of Deliverables

  • A revised set of WS-Notification specifications (WS-Base Notification, WS-Topics, WS-Brokered Notification). Committee Drafts due within one year of the first meeting.
  • A WS-NotificationPolicy specification detailing the policy language associated with Notification. Committee Draft due within one year of the first meeting.
  • A primer introducing the above specifications, including use cases, scenarios and suggested best practices for domain experts, as appropriate. Committee Draft due within one year of the first meeting.

These specifications will reflect refinements and changes made to, and by, contributions to the TC that are identified by members for additional functionality and semantic clarity within the scope of the TC charter. The TC may choose to vary the number of the specification documents and their titles.

Anticipated Audience for WSN TC Deliverables

The anticipated audience for this work includes:

  • other specification writers that need the notification pattern for Web services
  • vendors offering web service or message oriented middleware products
  • software architects and programmers who design and write distributed applications requiring notification

Identification of Existing Activities

A number of efforts that use or require the notification pattern in Web services are underway throughout the industry. The following work may be relevant to this Web Services Notification TC:

WSN TC Proposers

The following eligible people are in support of this proposal:


Principal references:


Hosted By
OASIS - Organization for the Advancement of Structured Information Standards

Sponsored By

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation

Primeton

XML Daily Newslink
Receive daily news updates from Managing Editor, Robin Cover.

 Newsletter Subscription
 Newsletter Archives
Bottom Globe Image

Document URI: http://xml.coverpages.org/ni2004-03-10-b.html  —  Legal stuff
Robin Cover, Editor: robin@oasis-open.org