General reference document on statefulness in web services. [Draft document in preparation. Provisional and incomplete]
- Initiatives and Projects
- Open Grid Services Infrastructure Working Group (OGSI WG)
- Web Services Resource Framework
- Web Services Notification Framework
- North-East Regional e-Science Centre (NERESC)
- W3C Web Services Description Working Group
- Business Process Execution Language (BPEL)
- OASIS Web Services Resource Framework Technical Committee
- OASIS Web Services Notification Technical Committee
- OASIS Web Services Composite Application Framework TC
- General: Articles, Papers, Presentations, Reports, News
References to key specifications (being) produced within several working groups, technical committees, and industry initiatives. [Incomplete, intended to be representative].
"The purpose of the OGSI Working Group is to review and refine the Grid Service Specification and other documents that derive from this specification, including OGSA-infrastructure-related technical specifications and supporting informational documents. On January 20, 2004, as new set of draft specifications was released based on the concepts of OGSI and enhanced by experts from the Web Services community." The new documents are called the WS-Resource Framework (WSRF). [home page]
The OGSI Version 1.0 specification was completed in June 2003 and released in July 2003. One of the principal objectives of the OGSI specification is the "identification and description of the state which is the target of messages also enables a standard approach, called 'statefulness', to managing interactions between systems and their users." From the V1.0 abstract: "Building on both Grid and Web services technologies, the Open Grid Services Infrastructure (OGSI) defines mechanisms for creating, managing, and exchanging information among entities called Grid services. Succinctly, a Grid service is a Web service that conforms to a set of conventions (interfaces and behaviors) that define how a client interacts with a Grid service. These conventions, and other OGSI mechanisms associated with Grid service creation and discovery, provide for the controlled, fault-resilient, and secure management of the distributed and often long-lived state that is commonly required in advanced distributed applications. In a separate document, we have presented in detail the motivation, requirements, structure, and applications that underlie OGSI. Here we focus on technical details, providing a full specification of the behaviors and Web Service Definition Language (WSDL) interfaces that define a Grid service."
- OGSI WG web site
- OGSI WG Charter. Edited by David Snelling. 2003-07-15 or later. Final version of revised WG charter, covering activities after OGSI Specification V1.0.
- Open Grid Services Infrastructure (OGSI) Version 1.0. From the Open Grid Services Infrastructure Working Group (OGSI-WG). Edited by S. Tuecke (ANL), I. Foster (ANL), J. Frey (IBM), S. Graham (IBM), C. Kesselman (USC/ISI), T. Maquire (IBM), T. Sandholm (ANL), D. Snelling (Fujitsu Labs), and P. Vanderbilt (NASA). Reference: GWD-R (draft-ggf-ogsi-gridservice-33) June 27, 2003. 86 pages.
- "Open Grid Service Infrastructure Primer." Reference: 'draft-ggf-ogsi-gridserviceprimer-4'. February 11, 2004 or later. 75 pages.
- OGSI::Lite - Perl Grid Services. "OGSI::Lite (formerly ILCT) is an experiment in creating a Grid Services Container using Perl. It is based on the excellent Perl SOAP::Lite and associated modules. It supports lifetimes, stateful services, factories, notification and ServiceGroups. We aim to make it fully OGSI compliant." See Mark 's posting of 2004-02-10, re: WSRF
- University of Virginia Grid Computing Group's OGSI.NET project pages. "These pages provide information about our OGSI.NET project and links to our software and installation instructions. In short, OGSI.NET is a platform for grid computing on .NET and a bridge to grid computing solutions on Unix machines. The latest release is OGSI.NET 2.1. It includes a OGSI-compliant hosting container and many example services and several clients including a graphical browser..."
- Global Grid Forum (GGF). "GGF is a community-initiated forum of thousands of individuals from industry and research leading the global standardization effort for grid computing. GGF's primary objectives are to promote and support the development, deployment, and implementation of Grid technologies and applications via the creation and documentation of "best practices" - technical specifications, user experiences, and implementation guidelines." See the structure document.
Description from the March 05, 2004 overview document:
"The WS-Resource construct has been proposed as a means of expressing the relationship between stateful resources and Web services. The WS-Resource framework is 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.
[The WS-Resource Framework overview] 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.
The WS-Resource framework is inspired by the work of the Global Grid Forum's Open Grid Services Infrastructure (OGSI) Working Group. Indeed, it can be viewed as a straightforward refactoring of the concepts and interfaces developed in the OGSI V1.0 specification in a manner that exploits recent developments in Web services architecture (e.g., WS-Addressing)..."
A WS-Resource is defined as the composition of a Web service and a stateful resource that is (i) expressed as an association of an XML document with defined type with a Web services portType, and (ii) addressed and accessed according to the implied resource pattern, a conventional use of WS-Addressing endpoint references... Web service endpoint reference (WS-Addressing) can be renewed in the event the addressing or policy information contained within it becomes invalid or stale (WS-RenewableReferences)..." [The WS-Resource Framework 2004-03-05]
- The WS-Resource Framework. Overview document. Version 1.0. March 05, 2004.
- WS-Resource Framework. References from the Globus Alliance.
- WS-Resource Framework FAQ document. By Ian Foster and David Snelling. From the Globus Alliance.
- Web Services Resource Framework. References from IBM.
- References from HP
- WSRF.net. Planned website related to the University of Virginia Grid Computing Group's OGSI.NET project pages.
- "Web Services Notification and Web Services Resource Framework." News story January 20, 2004.
- OASIS WSRF Technical Committee
A Web Services Notification Framework was announced on March 05, 2004. The papers and specifications were developed by Akamai Technologies, Computer Associates International, Fujitsu Laboratories of Europe, Globus, Hewlett-Packard, IBM, SAP AG, Sonic Software, and TIBCO Software.
Description from IBM's "Web Services Notification" document:
"The Event-driven, or Notification-based, interaction pattern is a commonly used pattern for inter-object communications. Examples exist in many domains, for example in publish/subscribe systems provided by Message Oriented Middleware vendors, or in system and device management domains. This notification pattern is increasingly being used in a Web services context.
WS-Notification is a family of related white papers and specifications that define a standard Web services approach to notification using a topic-based publish/subscribe pattern. It includes:
- Standard message exchanges to be implemented by service providers that wish to participate in Notifications
- Standard message exchanges for a notification broker service provider (allowing publication of messages from entities that are not themselves service providers)
- Operational requirements expected of service providers and requestors that participate in notifications
- An XML model that describes topics..."
- "Web Services Notification Framework for Publish-Subscribe Notification Events."
- Web Services Notification Framework. From IBM.
- Web Services Notification. References from SAP.
- WS-Notification Specifications. References from HP.
- Web Services Notification and Web Services Resource Framework. Reference from IBM.
- Publish-Subscribe Notification for Web Services White paper. This document introduces the concepts of notification patterns and sets the goals and requirements for the WS-Notification family of specifications. See the overview.
- WS-Notification Framework specifications:
"The NEReSC at University of Newcastle, Newcastle-upon-Tyne was established in July 2001, funded by the EPSRC and DTI through the UK Core e-Science programme, to provide expertise in e-Science and to instigate and run a set of industrially focused projects."
- "Grid-Resource Specification." By Savas Parastatidis, Paul Watson, and Jim Webber. Version 1.0. October 01, 2003. 7 pages. "This specification defines the Grid Resource Identifier for globally naming resources and the Grid Resource Metadata document which may contain metadata information for those resources." Also in PDF format [cache]
- "A Grid Application Framework based on Web Services Specifications and Practices." Document version: 1.0. Date published: 12 August 2003. 28 pages. "This document presents an analysis of the Grid architecture and its relationship to the Web Services Architecture. It presents our views on the current version of the OGSI specification and then goes on to propose a different mapping of the Grid infrastructure requirements to Web Services specifications and practices. The aim is to design an alternative mapping that captures the same Grid requirements, but fits more closely with existing Web Services specifications and practices."
- WS-GAF reference page
- WS-GAF FAQ document
- "Web and Grid Services: Architectures and Technologies," by Savas Parastatidis
- Web Services Grid Application Framework (WS-GAF).
- NEReSC web site
Relationship to OGSI and WSRF: The OGSI specification version 1.0 "defines a set of conventions and extensions on the use of Web Service Definition Language (WSDL) and XML Schema to enable stateful Web services." One of the criticisms of OGSI v1.0 was the "introduction of forthcoming WSDL 2.0 capability as unsupported extensions to WSDL 1.1. The OGSI authors exploited constructs from the proposed WSDL 2.0 draft specification. Delays in the publication of WSDL 2.0 made it more difficult to support the OGSI definition with existing Web services tooling and runtimes. Therefore, it is beneficial to express the capabilities of OGSI using the WSDL 1.1 definition to avoid the requirement for extended tooling... OGSI's GWSDL extension to the WSDL 1.1 portType is mainly syntactic sugar, to allow for interface extension. In addition, GWSDL went beyond syntactic sugar with the declaration of service data as part of an interface definition. Unfortunately, GWSDL was a major barrier to the use of OGSI. Thus, the WS-Resource Framework simply defines its messages in terms of WSDL 1.1, and requires that designers of composite interfaces copy-and-paste together the components of such an interface until WSDL 2.0 is completed... The removal of GWSDL means that we must instead copy-and-paste messages and resource property elements when creating composite interfaces in WSDL 1.1. This requirement will disappear with the proposed WSDL 2.0 definition, which has the same interface extension as OGSI's GWSDL..." [from Refactoring and Evolution]
- Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language. W3C Working Draft. 10-November-2003.
- W3C Web Services Activity
- W3C Web Services Description Working Group
Managing (event) state is relevant to many of the transaction coordination and "choreography" specifications. WSBPEL is an important specification, though not the only one relevant to Web services.
Description from the Version 1.1 specification abstract:
"This document defines a notation for specifying business process behavior based on Web Services. This notation is called Business Process Execution Language for Web Services... Processes in BPEL4WS export and import functionality by using Web Service interfaces exclusively.
Business processes can be described in two ways. Executable business processes model actual behavior of a participant in a business interaction. Business protocols, in contrast, use process descriptions that specify the mutually visible message exchange behavior of each of the parties involved in the protocol, without revealing their internal behavior. The process descriptions for business protocols are called abstract processes. BPEL4WS is meant to be used to model the behavior of both executable and abstract processes.
BPEL4WS provides a language for the formal specification of business processes and business interaction protocols. By doing so, it extends the Web Services interaction model and enables it to support business transactions. BPEL4WS defines an interoperable integration model that should facilitate the expansion of automated process integration in both the intra-corporate and the business-to-business spaces..."
- "Business Process Execution Language for Web Services. Version 1.1. 5 May 2003.
- OASIS Web Services Business Process Execution Language TC web site
- "Messaging and Transaction Coordination." - General references for transaction specifications.
- "Business Process Execution Language for Web Services (BPEL4WS)" - local references
- See also: Asynchronous Transactions and Web Services
- See also: Standards for Business Process Modeling, Collaboration, and Choreography
On March 09, 2004 OASIS announced the formation of a Web Services Resource Framework (WSRF) Technical Committee. See the announcement: "Web Services Resource Framework TC Call for Participation." See details in "OASIS Forms TCs for Web Services Resource Framework and Web Services Notification."
From the TC Charter:
"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.
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..."
- OASIS Web Services Resource Framework TC web site
- TC Charter
- TC list archives
- "OASIS Forms TCs for Web Services Resource Framework and Web Services Notification." News story 2004-03-10.
- See: Web Services Resource Framework principal reference
- OASIS Announcement 2004-03-17: "OASIS Members Organize to Define Stateful Resources Using Web Services. AmberPoint, Arjuna Technologies, BEA Systems, BMC Software, Computer Associates, Fujitsu, HP, IBM, NEC, Novell, OpenNetwork, Ricoh, SeeBeyond, Sonic Software, webMethods, and Others Advance Open Framework."
On March 09, 2004 OASIS announced the formation of a Web Services Notification (WSN) Technical Committee. See details in the text of the announcement: "OASIS TC Call for Participation: Web Services Notification." See details in "OASIS Forms TCs for Web Services Resource Framework and Web Services Notification."
From the TC Charter:
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:
- 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.
- 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.
- 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.
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... 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 TC will coordinate with the [proposed OASIS] 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.
- "Web Services Notification Framework for Publish-Subscribe Notification Events." News story 2004-03-05.
- OASIS Web Services Notification TC web site
- TC Charter
- TC list archives
- "OASIS Forms TCs for Web Services Resource Framework and Web Services Notification." News story 2004-03-10.
- Web Services Notification Framework principal reference
- OASIS Announcement 2004-03-17: "OASIS Members Collaborate to Advance Web Services Notification. AmberPoint, Arjuna Technologies, BEA Systems, BMC Software, Computer Associates, Fujitsu, HP, IBM, NEC, Novell, OpenNetwork, SAP, SeeBeyond, Sonic Software, webMethods, and Others to Standardize Web Services Interactions."
The OASIS Web Services Composite Application Framework TC was chartered to "define a generic and open framework for applications that contain multiple services used in combination (composite applications). Multiple web services combined in composite applications require interoperable mechanisms to set the boundaries of an activity (such as start/end, or success/failure), to create, access and manage context information, and to inform participants of changes to an activity. Composite applications might also need to work with a range of transaction models, including simple activity scoping, single and two phase commit ACID transactions, and recoverable long running activities..."
Background to the TC work is found in the WS-CAF specifications published by Arjuna Technologies Limited, Fujitsu Software, IONA Technologies PLC, Oracle Corp and Sun Microsystems:
Web Service Context (WS-CTX) is "a lightweight framework for simple context management that helps enable all Web services participating in an activity share a common context and exchange information about a common outcome... The context information is specific to the type of activity being performed, such as to identify a transaction coordinator, the other participants in an activity, or recovery information in the event of a failure, etc. Therefore, a single context type is not sufficient for all types of activity that a Context Service may be required to support. Hence, the capabilities of the Context Service must be extensible in an application specific manner and services must be able to augment the context as they require to suit their own particular application domains...."
Web Service Coordination Framework (WS-CF) is "a sharable mechanism that manages context augmentation and lifecycle and provides the notification of outcome messages to Web services participating in a particular transaction... Coordination is a fundamental requirement of many distributed systems, including Web Services. However, the type of coordination protocol that is used may vary depending upon the circumstances (e.g., two-phase versus three-phase). Therefore, what is needed is a standardization on a coordination framework (coordination service) that allows users and services to register with it, and customize it on a per service or per application basis..."
Web Services Transaction Management (WS-TXM) "is comprised of three distinct, interoperable transaction protocols that can be used across multiple transaction managers. WS-TXM supports multiple transaction models to help enable participants to negotiate outcomes with each other and make a common decision about how to behave, especially in the case of failure, regardless whether the execution environment is CORBA, Enterprise JavaBeans (EJB), .NET, Java Message Service (JMS), or some combination... traditional transactions depend upon tightly coupled protocols, and thus are often not well suited to more loosely-coupled Web services based applications, although they are likely to be used in some of the constituent technologies. It is more likely that traditional transactions are used in the minority of cases in which the cooperating Web services can take advantage of them, while new mechanisms, such as compensation, replay, and persisting business process state, more suited to Web services are developed and used for the more typical case..."
- OASIS Web Services Composite Application Framework TC web site
- "OASIS Forms Web Services Composite Application Framework Technical Committee." News story 2003-09-18.
- "Web Services Composite Application Framework (WS-CAF) for Transaction Coordination." News story 2003-07-29.
In July 2003, HP announced the publication of a Web Services Management Framework Version 2.0 and plans to contribute the specification set to the OASIS Web Services Distributed Management TC. The WS-Events component in this framework defines the Web services based event notification mechanism and is used by WSMF-Foundation. In this specification: "An event is a change in the state of a resource or request for processing; An event producer is an entity which generates notifications; An event consumer is a receiver of notifications; An event broker is an entity which routes notifications. Brokers typically aggregate and publish events from other producers. An event broker can also apply some transformation to the notifications it processes."
Web Services Events (WS-Events) Version 2.0. Edited by Nicolas Catania (Hewlett-Packard Company). 16 July 2003. 23 pages. Authors: Pankaj Kumar (Hewlett-Packard Company), Bryan Murray (Hewlett-Packard Company), Homayoun Pourhedari (Hewlett-Packard Company), William Vambenepe (Hewlett-Packard Company), and Klaus Wurster (Hewlett-Packard Company). See also the WS-Events XML schema and WS-Events WSDL. "This document describes Web Services Events (WS-Events) Version 2.0, an XML syntax and a set of processing rules for advertising, subscribing, producing and consuming Web Services Events. An Event is an abstract concept that is physically represented by a Notification. Notifications flow from Event producer to Event consumer using asynchronous or synchronous delivery modes (push/pull)."
In January 2004 a draft version of Web Services Eventing (WS-Eventing) was published as a new member of the 'Composable Architecture' (WS-*) Web service specifications. The WS-Eventing specification "describes a protocol that allows Web services to subscribe to or accept subscriptions for event notification messages." An example request to create a subscription for storm warnings is used to illustrate the notification protocol. "Web services often want to receive messages when events occur in other services and applications. A mechanism for registering interest is needed because the set of Web services interested in receiving such messages is often unknown in advance or will change over time." Formal models for the protocol are provided in the XML Schema and WSDL files. Supporting both SOAP 1.1 and SOAP 1.2 Envelopes, the specification intends to define a "means to create and delete event subscriptions, to define expiration for subscriptions, and to allow them to be renewed. It defines how an event sink can determine which subscriptions it is receiving notifications for, and how one event sink can subscribe on behalf of another. The specification is meant to leverage other Web service specifications for secure, reliable, transacted message delivery. It provides extensibility for more sophisticated and/or currently unanticipated subscription scenarios."
- "BEA, Microsoft, and Tibco Release Web Services Eventing (WS-Eventing) Specification". News story 2004-01-07.
- Web Services Eventing (WS-Eventing). By Luis Felipe Cabrera (Microsoft), Craig Critchley (Microsoft), Gopal Kakivaya (Microsoft), Brad Lovering (Microsoft), Matt Mihic (BEA Systems), David Orchard (BEA Systems), Shivajee Samdarshi (TIBCO Software), Jeffrey Schlimmer (Editor, Microsoft), John Shewchuk (Microsoft), and David Wortendyke (Microsoft). January 2004. Copyright (c) 2004 BEA Systems Inc., Microsoft Corporation, and Tibco Software Inc. 31 pages (PDF). Acknowledgements: "This specification has been developed as a result of joint work with many individuals and teams, including: Don Box (Microsoft), Josh Cohen (Microsoft), Geary Eppley (Microsoft), Omri Gazitt (Microsoft), Peter Jarvis (Microsoft), Chris Kaler (Microsoft), Amy Lewis (TIBCO Software), Toby Nixon (Microsoft), Denny Page (TIBCO Software), Anders Vinberg (Microsoft), Alex Weinert (Microsoft)."
"WS-Addressing provides transport-neutral mechanisms to address Web services and messages. Specifically, this specification defines XML elements to identify Web service endpoints and to secure end-to-end endpoint identification in messages. This specification enables messaging systems to support message transmission through networks that include processing nodes such as endpoint managers, firewalls, and gateways in a transport-neutral manner." [Specification abstract]
"WS-Addressing provides a simple yet powerful mechanism called an endpoint reference for addressing entities managed by a service. While such information could be encoded in an ad-hoc manner within the URL of the service, the endpoint references provides a standard XML element that enables a structured approach to encoding this fine-grained addressing. The combination of fine-grain control over addressing coupled with the transport-neutral encoding of the message source and destination enables Web service messages to be sent across a range of transports, through intermediaries, and it enables both asynchronous and extended duration communication patterns..." [from "Secure, Reliable, Transacted Web Services: Architecture and Composition"]
- "Web Services Addressing (WS-Addressing)"
- Web Services Addressing (WS-Addressing). "13 March 2003." (Revised version) Published about May 19/23, 2003. Copyright (c) 2002-2003 by BEA Systems Inc., International Business Machines Corporation, Microsoft Corporation. 14 pages.
- WS-Addressing XML Schema
[March 07, 2005] "Exploring WS-Notification: Building a Scalable Domotic Infrastructure." By Marco Aiello (Assistant Professor and Head of the Distributed Systems and Service-Oriented Computing Research Program, DIT, University of Trento, Italy), Manuel Zanoni, and Alessandro Zolet. In Dr. Dobb's Journal (April 2005), pages 48-51. "Home appliances are evolving at a pace well beyond the capabilities designers of X10 -- a standard that uses powerlines to remotely control home devices -- ever expected. Equipping home devices with processors and wireless connectivity has become affordable and painless, thanks in part to wireless connectivity Standards such as GSM, GPRS, Wi-Fi (IEEE 802.11), Bluetooth (IEEE 802.15.1), and ZigBee (IEEE 802.15.4). Still, one of the challenges users face is having devices that make proper use of this communication infrastructure. What are appropriate messaging schemes for these loosely coupled autonomous devices? How can these devices discover each other and interact? Interestingly, XML-based web services offer an answer to this question. In this article, we will examine WS-Notification, a web-service publish/subscribe protocol that we apply to a "domotic" living environment for elderly adults. In particular, we use WS-Notification to integrate different sensors and actuators in a home environment, with the goal of detecting life-threatening situations, such as when elderly inhabitants of the home fall... With WS-Notification, you have standard ways for creating an ontology of topics for describing events, a communication mechanism between event producers and consumers, and a policy for subscriptions and event forwarding. In short, WS-Notification lets you build platform-independent scalable systems made of autonomous nodes asynchronously exchanging messages — exactly what you need in the context of domotics... We have deployed the WS-Notification server in a home with the goal of monitoring elderly citizens and detecting if they fall. Indeed, one of the most common accidents in the aging population is the accidental fall that, especially if undetected, may have dangerous effects. In Great Britain, accidental falls constitute about 30 percent of the home accidents of people over 65. A number of sensors can be used to detect this hazardous situation; for instance, one can place an array of infrared sensors at the floor level, one can equip the person with an accelerometer, or one can use fixed cameras. With the notification server, we can actually combine more sensors to reduce the amount of false positives. In particular, we use a custom-made accelerometer built by ITC-irst and standard fixed video cameras. State-of-the-art posture-recognition software built by CNR-IMAG lecce analyzes the images and classifies postures into three main categories: standing, sitting, and laying. The rule engine fuses the data from the accelerometer and image-analysis software, and identifies potentially dangerous situations. The information of each sensor taken alone is not enough to detect a fall with an acceptable reliability. Home networking in general and domotics in particular are applications where WS-Notification can be successfully applied. While not all home appliances will implement a web-service stack that goes from SOAP messages up to WSDL or even BPEL descriptions, many will aggregate home functional units and offer interfaces for the external world (and vice versa). Home sensor networks will have different forms of computationally less-expensive communication and will use web-service-ready devices as gateways for higher level communication..." See similarly online "Opening the Home: A Web Service Approach to Domotics" (entry following).
[March 07, 2005] "Opening the Home: A Web Service Approach to Domotics." By Marco Aiello and Maurizio Marchese (DIT - Univ. of Trento); Paolo Busetta and Gaetano Calabrese (ITC-irst). Technical Report #DIT-04-109, University of Trento, Department of Information and Communication Technology, December 2004. 14 pages. "The pervasiveness of smart appliances in the home, the increase of computational power of traditional home appliances, and the widespread adoption of wireless networking are creating a unique opportunity in domotics. The challenge lies in moving from a set of isolated devices towards a network of home appliances interoperating and scaling seamlessly to provide services to the home user. The major barriers to achieve this is the abundance of non-interoperable domotics standards and the lack of a generally agreed architecture. We propose a service-oriented architecture (SOA) for the interaction of home appliances and the creation of value added services based on standard web services. In particular, we propose the use of WS-Notification as the basic layer for device interoperation. We have experimented the proposed architecture in the context of a project for the assistance of the elder citizen. We provide preliminary results for the case of fall-detection. Addressing the operability of different sensors yields, for the first time, to an integrated and scalable system that detects falls by fusing data transported via a truly vendor-independent publish/subscribe mechanism... The novelty of the approach lies in the openness of the resulting home network where any device is seamlessly added and removed independently of its hardware, operating system and network interface. The approach is based on WS-Notification. To the best of our knowledge, this is the first implementation of the standard in a prototype deployed for a concrete application. The WS-Notification server has been implemented and tests are underway in a real home environment where two type of sensors have been deployed: a wearable custom accelerometer and a videocamera. Furthermore, registration of events and modification of the event tree is performed by a PDA. The test case is the fall detection of the elderly at home. Previous approaches to fall detection have used one sensor only. The open architecture we propose allows the use of distinct sensors for fall detection..."
[May 01, 2004] "Stateful Interactions in Web Services: A Comparison of WS-Context and WS-Resource Framework." By Mark Little (Arjuna Technologies Limited), Jim Webber (University of Newcastle upon Tyne), and Savas Parastatidis (North-East Regional e-Science Center - NEReSC, Newcastle, UK). In Web Services Journal Volume 4, Issue 5 (May 2004). "In July 2003 a consortium of Web services vendors released the Web services Composite Application Framework (WS-CAF) to the community. WS-CAF is comprised of three specifications that together provide a means of reliably composing individual Web services into larger aggregate applications. The cornerstone of this suite is the management of stateful interactions between Web services that is the domain of the WS-Context specification. WS-CAF was subsequently submitted to OASIS and an effort to standardize the framework is currently underway. In January 2004 a group of industry and academic practitioners from the Grid community released [the first parts of] the Web Services Resource Framework specifications. WS-RF will support stateful interactions between consumers and resources hosted by Web services. Clearly there is some overlap between the WS-Context and WS-RF approaches since both support stateful interactions on top of the stateless interaction model championed by Web Services Architecture (WSA). This article examines the different approaches taken by WS-Context and WS-RF, concentrating in particular on how each approach facilitates stateful interactions in composite Web services-based applications... While both WS-Context and WS-RF can be used to enable stateful interactions between Web services and their consumers, the models they adopt to achieve this are very different, and as a consequence the scenarios in which they are best deployed are also different. The WS-RF approach is based on an addressing scheme for back-end resources hosted by Web services. This addressing information can be used as a means of correlating and routing message exchanges with those back-end resources and thus as a means of achieving stateful communication. WS-Context assumes that the back-end implementation details of a service are private. It is deliberately noninvasive and deals only with context management and propagation of contexts to services. What precisely is done to map a particular application level message plus context onto specific back-end resources is safely out of scope. For single consumer-server interactions the WS-RF approach is certainly lightweight. However for interactions involving multiple services, the WS-Context approach scales readily to support distributed activities. Thus WS-RF might be suitable as a point-to-point solution for integrating two systems, but in the general case with systems composed from many Web services, WS-Context is the natural choice..."
[March 05, 2004] From Open Grid Services Infrastructure to WS-Resource Framework: Refactoring and Evolution. Version 1.1. March 05, 2004. 20 pages. By Karl Czajkowski (Globus Alliance / USC Information Sciences Institute), Don Ferguson (IBM), Ian Foster (Globus Alliance / Argonne National Laboratory), Jeff Frey (IBM), Steve Graham (IBM), Tom Maguire (IBM), David Snelling (Fujitsu Laboratories of Europe), and Steve Tuecke (Globus Alliance / Argonne National Laboratory). With contributions and feedback from Sonny Fulkerson, Carl Kesselman, Susan Malaika, Martin Nally, Jeff Nick, Chris Sharp, Tony Storey, and Jay Unger, also from Malcolm Atkinson and Savas Parastatidis. "The Open Grid Services Infrastructure specification version 1.0 (OGSI), released in July 2003, defines a set of conventions and extensions on the use of Web Service Definition Language and XML Schema to enable stateful Web services. It introduces the idea of a stateful Web services and defines approaches for creating, naming, and managing the lifetime of instances of services; for declaring and inspecting service state data; for asynchronous notification of service state change; for representing and managing collections of service instances; and for common handling of service invocation faults. In January 2004, the WS-Resource Framework was proposed as a refactoring and evolution of OGSI aimed at exploiting new Web services standards, specifically WS-Addressing, and at evolving OGSI based on early implementation and application experiences. The WS-Resource Framework retains essentially all of the functional capabilities present in OGSI, while changing some of the syntax (e.g., to exploit WS-Addressing) and also adopting a different terminology in its presentation. In addition, the WS-Resource Framework partitions OGSI functionality into five distinct, composable specifications. In this document, we explain the relationship between OGSI and the WS-Resource Framework and the related WS-Notification family of specifications, explain the common requirements that both address, and compare and contrast the approaches taken to the realization of those requirements." See also the overview page from IBM. [source PDF]
[March 05, 2004] The WS-Resource Framework. By Karl Czajkowski (Globus Alliance / USC Information Sciences Institute), Donald F Ferguson (IBM), Ian Foster (Globus Alliance / Argonne National Laboratory), Jeffrey Frey (IBM), Steve Graham (IBM), Igor Sedukhin (Computer Associates International), David Snelling (Fujitsu Laboratories of Europe), Steve Tuecke (Globus Alliance / Argonne National Laboratory), and William Vambenepe (Hewlett-Packard). Version 1.0. March 05, 2004. 18 pages. "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." [source PDF]
[March 05, 2004] "Web Services Notification Framework for Publish-Subscribe Notification Events." The technology previously outlined in a Web Services Notification (WS-Notification) specification has been elaborated in terms of a Web Services Notification Framework which supports Publish-Subscribe Notification for Web services. This framework has been developed by Akamai Technologies, Computer Associates International, Fujitsu Laboratories of Europe, Globus, Hewlett-Packard, IBM, SAP AG, Sonic Software, and TIBCO Software. The Web Services Notification Framework complements [and is part of] the Web Services Resource Framework, which includes the WS-ResourceProperties and WS-ResourceLifetime specifications and defines a family of specifications for accessing stateful resources using Web services. The Web Services Notification Framework currently includes three normative specifications. Web Services Base Notification (WS-Base Notification) describes "standard message exchanges to be implemented by service providers that wish to act in these roles, along with operational requirements expected of them." Web Services Brokered Notification (WS-BrokeredNotification) "defines the Web services interface for the NotificationBroker, which is an intermediary that allows publication of messages from entities that are not themselves service providers." Web Services Topics (WS-Topics) "defines a mechanism to organize and categorize items of interest for subscription known as 'topics' that are used in conjunction with the notification mechanisms defined in WS-Base Notification. It defines three topic expression dialects and specifies an XML model for describing metadata associated with topics." These specifications "implement the Notification pattern in which a service provider, or other entity, initiates messages based on a subscription or registration of interest from a service requestor. The Web Services Notification Framework defines how the publish/subscribe (pub/sub) pattern commonly used in Message-Oriented middleware products can be realized using Web services. This includes brokered as well as direct pub/sub which allows the publisher/subscribers to be decoupled and provides greater scalability..."
[March 05, 2004] Modeling Stateful Resources with Web Services. Version 1.1. 03/05/2004. By Ian Foster (Globus Alliance / Argonne National Laboratory, Editor), Jeffrey Frey (IBM, Editor), Steve Graham (IBM, Editor), Steve Tuecke (Globus Alliance / Argonne National Laboratory, Editor), Karl Czajkowski (Globus Alliance / USC ISI), Don Ferguson (IBM), Frank Leymann (IBM), Martin Nally (IBM), Igor Sedukhin (Computer Associates International), David Snelling (Fujitsu Laboratories of Europe), Tony Storey (IBM), William Vambenepe (Hewlett-Packard), and Sanjiva Weerawarana (IBM). Copyright (c) 2003, 2004 Computer Associates International, Inc., Fujitsu Limited, Hewlett-Packard Development Company, International Business Machines Corporation and The University of Chicago. 24 pages. "The Web services architecture has been broadly accepted as a means of structuring interactions among distributed software services. Further standardization is now required to facilitate additional interoperability among services. One important area in which further standardization is required concerns interactions with stateful resources. In this paper, we address the constructs used to enable Web services to access state in a consistent and interoperable manner. We introduce the WS-Resource approach to declaring and implementing the association between a Web service and one or more named typed state components. In this approach, we model state as stateful resources and codify the relationship between Web services and stateful resources in terms of the implied resource pattern, a set of conventions on Web services technologies, in particular WS-Addressing. We describe a WS-Resource in terms of a stateful resource and its associated Web service. We also describe an approach for making the properties of a WS-Resource accessible through its Web service interface, and for managing a WS-Resource's lifetime."
[February 26, 2004] "Grid Forum Backs Utility Computing Standards." By Paul Shread. From GridComputingPlanet.com (February 25, 2004). "The Distributed Management Task Force's effort to draft standards for utility computing has received the backing of the Global Grid Forum (GGF), the Grid computing standards-setting body. 'This is an important activity and we are excited to see the DMTF bring this group together, while simultaneously tapping related efforts, such as GGF's Open Grid Services Architecture (OGSA) and several new GGF research groups focused on commercial enterprise Grid application use cases and requirements,' Charlie Catlett, senior fellow at Argonne National Laboratory and chair of GGF, said in a statement... 'We have been working very closely with both DMTF for the past year, and in the past six months, also with OASIS, because these things are converging,' Catlett said. 'The efforts are indeed complementary, and where we have found intersection of activities we have created high-bandwidth liaison activities. For instance, we have a Common Management Model working group within GGF that was created by some folks who also participate in DMTF, and one of the objectives is cross-fertilization between Grid/utility computing and the distributed systems management world.' Catlett said 'the best sign of convergence' is the WS-Resource Framework (WSRF) effort to recast several key components of GGF's Open Grid Services Infrastructure (OGSI) specification into a set of Web services specs. The work is a joint effort between Grid services proponents from the GGF community and Web services proponents, Catlett said. 'The path forward for this is that WSRF specifications are most likely to be standardized via OASIS, where most Web services work is happening these days,' Catlett said. The GGF OGSI working group will serve a liaison function, and Catlett said he expects the WSRF-related OASIS technical committees to hold meetings at the thrice-yearly Grid forums. 'These are only a few of the ways we are discussing to work together with OASIS and DMTF,' Catlett said. Catlett also said he is 'personally very intrigued by DCML,' the Data Center Markup Language effort, and is 'trying to figure out how it might fit into Grid projects that I am doing without my GGF hat on. I definitely think DCML is quite interesting, but I have not followed what they're doing. We had extended an offer to them to do the work within GGF, but we haven't followed up. Regardless of where the work is done, I am hoping that we can form a liaison activity with them to make sure there is good exchange of ideas with the Grid community'..." See the announcement "DMTF Announces New Working Group for Utility Computing. OASIS, GGF and Industry Leaders Join Forces with DMTF to Further Management Standards for Utility Computing."
[February 20, 2004] "Ian Foster on Recent Changes in the Grid Community." By Mark Baker (School of Computer Science, University of Portsmouth, UK) and Dejan Milojicic. In IEEE Distributed Systems Online Volume 5, Number 2 (February 2004). ['Mark Baker contacted Ian Foster (Senior Scientist, Distributed Systems Lab, Argonne National Laboratory; Arthur Holly Compton Professor of Computer Science, University of Chicago) just after the announcement of WSRF to discuss the recent changes and to get an idea of how these will affect the Grid community.'] Foster: "... The WSRF proposal is a refactoring of OGSI concepts to align better with Web services. The need for this refactoring became apparent when Web services vendors indicated that while they recognized the importance of OGSI concepts, they would not adopt OGSI as it was then defined. This response threatened to prevent the ubiquitous support for Grid infrastructure that was a primary motivator for OGSI. So, while we in the Globus Alliance had little enthusiasm for revisiting the OGSI design (we'd much rather be developing higher-level services than fiddling with infrastructure), we concluded that some refactoring was justified if it could affect the convergence of Grid and Web services. We teamed up with Web services architects to study this issue, and the result is WSRF. The changes from OGSI to WSRF are primarily syntactic but also represent some useful progress. The separation of OGSI functionality into six independent specifications simplifies adoption, the use of WS-Addressing is a step forward, and less aggressive use of XML Schema and WSDL 2.0 features will facilitate the use of available tooling. Do these benefits justify the disruption associated with a revision to the Grid infrastructure specification? At a purely technical level, it's debatable, but the fact that we now have strong support in the Web services community for Grid infrastructure is a huge achievement: it means we'll see WSRF support in core Web services products, which is wonderful news for the Grid community. Also, we shouldn't overemphasize the magnitude of the change: while there's certainly some work involved in converting from OGSI to WSRF, it doesn't appear to be substantial, and we're working to ease this transition. ... A beautiful feature of OGSI/WSRF is its deep integration of information service mechanisms. Any Grid service (or WS-Resource in WSRF) can declare service data (resource properties) that can be discovered, pulled, or pushed using standard mechanisms. The WS-Notification specification introduced with WSRF moves us another important step toward robust, feature-rich information services, by establishing interfaces that allow the exploitation of widely used message-oriented middleware. Thus, for example, a programmer who develops a file transfer service need only define some appropriate service data (resource properties) for that service to become immediately discoverable and be monitored. Given this underpinning, it becomes possible to define a wide range of information service components for discovery, monitoring, archiving, fault detection, and so forth..."
[February 02, 2004] "New Specs Enrich Identity Federation." By James Kobielus. In Network World (February 02, 2004). "Last month, two industry groups released rival specifications that address the [event-notification services] requirement. One group — BEA Systems, Microsoft and Tibco Software — published a co-authored specification called Web Services Eventing (WS-Eventing); another, led by IBM, released its Web Services Notification (WS-Notification) spec. One important feature of WS-Eventing and WS-Notification is that they do not restrict the types or contents of messages that might serve as event notifications, nor do they restrict which entities might publish and subscribe to these messages. This means developers can begin to implement a general-purpose events infrastructure and, as Web services based on Simple Object Application Protocol become ubiquitous, make this infrastructure available to all applications and services. Notifications of user-generated events should be distributed in the same general-purpose infrastructure that handles system-level notifications. Inevitably, WS-Eventing and/or WS-Notification (or some converged specification that supersedes both) will be implemented in identity management systems to notify applications of important events concerning particular users. For example, an identity management environment might notify authorized applications that a user has connected to the network, logged on to a particular domain, moved to particular geographic coordinates and been granted particular roles, permissions and personalization settings... Liberty should reference WS-Eventing and/or WS-Notification in its identity management protocols, and the developers of WS-Federation should do likewise in future revisions. And as OASIS' Security Services Technical Committee continues development on SAML 2.0, it should begin to consider the need for a general-purpose event pub/sub environment for federated identity management. However, the SAML 2.0 feature list has more or less been finalized, and event notification isn't on it. Identity event notification will become a candidate for the eventual SAML 3.0 as soon as the federated identity management industry catches the vision and begins to compose standards with WS-Eventing and/or WS-Notification in mind..."
[January 26, 2004] "Web Services Event Standards Take Big Step Forward." By Roy W. Schulte and Massimo Pezzini (Gartner). Gartner Research Note. Note Number: FT-22-0670. "On 20 January 2004, Akamai, The Globus Alliance, Hewlett-Packard, IBM, Sonic Software and TIBCO Software proposed two new Web services specifications. The first, WS-Notification, seeks to provide a standards-based means of publish-and-subscribe message delivery. The second, WS-Resource Framework, is actually a set of three standards that collectively describe a way to describe, access and then clean up after expired resources, such as a contract. WS-Resource Framework is intended to make grid resources accessible as Web services and to enable better manageability of the resources. On 7-January-2004, BEA Systems, Microsoft and TIBCO also published a specification for a Web services publish-and-subscribe standard, known as WS-Eventing... Publish-and-subscribe communication has been an important omission in Web services standards. But now, vendors are moving faster than expected to standardize the basic publish-and-subscribe design pattern in a Web services manner, based on Simple Object Access Protocol (SOAP). Based on the newly proposed WS-Eventing and WS-Notification specs, publish-and-subscribe standards could be ratified as early as mid-2005 — although major challenges still exist..."
[January 23, 2004] "Grid and Web Services to Converge." By Peter Abrahams (Bloor Research). In IT-Analysis (January 23, 2004). "The two big computing ideas of the twenty first century grid computing and web services were brought closer together by an announcement this week at GlobusWorld the grid conference run by Globus Alliance. The Globus Alliance is a research and development project focused on enabling the application of Grid concepts to scientific and engineering computing and has developed the toolkit used by most scientific and university grid computing projects. It is an alliance between several university and laboratories in the US and Europe including Edinburgh. Web services have concentrated on creating an environment for 'applications on-demand' whereas grid has concentrated on providing 'computer-resources on-demand'. The announcement is made up of two new web services specifications that are necessary to make the grid computer resources available to the applications without the applications having to be grid aware. The two are the WS-Resource Framework and the WS-Notification specifications... WS-Resource Framework specification was contributed to by IBM, Globus and HP. It defines how to access a WS Resource through a web service. A web service is stateless whereas a WS-Resource is stateful, the state could be such things as data in a purchase order, current usage agreement for resources on a grid, or metrics associated with work load on a Web server. The framework describes a standard way to access a WS-resource by referencing it through an endpoint reference made up of the web services address and a resource id. It also defines how a web service can access or create new WS resources. The WS-Notification specification was contributed to by IBM, Globus, Akamai, HP, SAP, Tibco and Sonic. It provides a publish-subscribe messaging capability for Web Services. It enables changes or events to be published in a standard way and then notification send directly or via a broker. This is bringing some of Sonic's Enterprise Service Bus (ESB) concepts into a standards specification. WS-Notification is important for grid computing because it provides a standard way for grid resources such as web servers to notify grid schedulers of changes in state. Changes in state include coming on and off stream, being fully loaded or having spare capacity, having a fault that needs attention etc. All of this information is required for a grid scheduler to make informed decision on what resources to use next..."
[January 22, 2004] "Globus Details Roadmap for Toolkit. Grid Computing Software to Gain Performance, Reliability and Usability." By Joris Evers. In InfoWorld (January 22, 2004). "The Globus Alliance in March  plans to release an updated version of its Globus Toolkit for grid computing, adding performance, reliability and usability improvements and bug fixes since the 3.0 release last year, the group's co-leader said Wednesday. After the March release of version 3.2 the Globus Alliance plans to release version 4.0 in the third quarter, said Ian Foster, speaking at the GlobusWorld 2004 conference in San Francisco. A beta for the 3.2 release is set to start soon, he said. The 4.0 release of the Globus Toolkit will include draft WS-Resource Framework (WSRF) specifications, announced earlier this week at the GlobusWorld event. WSRF encompasses the WS-Resource Lifetime and WS-Resource Properties specifications introduced at the GlobusWorld event and intended to converge Web services and grid computing. WS-Resource Lifetime allows a user to specify a period during which a resource definition is valid and WS-Resource Properties defines how data associated with a stateful resource can be queried and changed using Web services technologies, according to a statement released Tuesday at GlobusWorld. 'We don't believe it is appropriate to wait for the specifications to wind their way through the standardization process to start implementing them,' Foster said. However, this does mean that the toolkit software will need revision when the final standards arrive, probably some time next year, but the toolkit will always offer backwards compatibility, he said. 'We are very concerned with supporting our existing user base and improving our software,' Foster said. The open source Globus Toolkit is a bundle of software to enable grid computing. It includes software services and libraries for resource monitoring, discovery and management, plus security and file management. The toolkit is a central part of science and engineering grid projects and used by IT vendors for commercial grid products..." See the following entry and Globus Toolkit web site.
[January 21, 2004] "WS-Notification Spec Released." By Dave Chappell (Vice President, Sonic Software). From O'Reilly Developer Weblogs (January 21, 2004). "We jointly announced the WS-Notification spec yesterday. The co-authors include IBM, Akamai, HP, SAP, Sonic Software, The Globus Alliance, and TIBCO... I would best describe WS-Notification as 'Pub-sub for the Internet'. Its a Distributed broker-based pub-sub using web service interfaces. It doesn't directly address QoS issues such as exactly-once delivery, although it is intended to be composable with WS-ReliableMessaging; in fact, its intended to be composable with the rest of the WS-* set of specifications... WS-Notification allows the use of a message broker, or a series of connected brokers, as intermediaries between producers and consumers. It Allows the use of proprietary MOM and bridging between proprietary MOM. I encourage you all to go read the spec. Here are some of the interesting items of note: (1) WS-Notification allows for a separate subscription broker that is able to subscribe on behalf of another subscriber. (2) While a 'Notification broker' is part of the spec, it allows for pub/sub to happen directly between the endpoints. The actual sending of the message works similarly. Publishers can send directly to other subscribers, or can send to a Notification Broker and let the Notification Broker take care of getting it to where it needs to go. (3) WS-Notification supports 'demand-based publishing' — Publishers can register with a Notification Broker and inform the broker about the list of topics it intends to publish on. This can be used at least a couple of ways — to authenticate the publisher and apply access control lists to limit the publisher to particular topics. It can also be used as a way for a Notification Broker to be able to manage the topic namespace such that it can apply optimizations such as suspending the publisher when there are no subscribers currently active. (4) The publisher need not be a web service. The publisher may act through a Notification producer which is Web service savvy... [As to] Publishing and Subscribing, WS-Notification supports a hierarchical tree-based topic space (much like SonicMQ). A subscriber can subscribe to entire branches at any level. Hierarchical topic trees allow subscribing to a Topic space that can include any branch in the tree using an Xpath-like 'TopicPathExpression'; security permissions may also be applied using the same mechanism. Publishers and Subscribers are referenced using WS-Addressing Endpoints. Message selectors are also supported using an Xpath-like notation. Message selectors allow a subscriber to filter a message based on a criteria. - There is also the notion of a 'precondition', which is sort of like a 'publish when' a certain condition occurs. Subscriptions may have a InitialTerminationTime, which governs how long the subscription is valid for. The whole lifecycle of resources is governed by a companion spec, WS-ResourceLifeTime..."
[January 22, 2004] "HP, IBM and Akamai Bring Web Services to Grid Computing." By Jay Lyman. From TechNewsWorld (January 21, 2004). "Rob Batchelder, industry analyst and president of IT consultancy Relevance, said that joining grid computing with Web services makes perfect sense... In an effort to pair and propel two emerging technologies, IBM, HP, Akamai, and other tech companies have proposed new specs to integrate grid computing with Web services. The companies, which announced the new WS-Notification and WS-Resource Framework specs, said the proposed standards represent the first availability of a common, standards-based infrastructure designed for business applications working in conjunction with grid resources... The proposed Web services specifications -- backed by IBM, HP, Akamai, the Globus Alliance, Sonic Software and Tibco -- are intended to define a scalable architecture that has the ability to connect resources (such as servers) to logical constructs (such as business agreements and contracts). The new standard would let customers perform just-in-time procurement with multiple suppliers who all adhere to the same specifications. Plus, the system would allow for grid-based workload balancing and the ability to detect system outages and recover from those outages automatically. One example of the standard in action would be suppliers automatically getting notified to replenish inventory once current inventory drops to a certain level. 'These new Web services specifications will significantly extend the types of enterprise solutions customers can easily deploy,' said IBM director of dynamic e-business technologies Karla Norsworthy. 'These new specifications provide customers with the ability to use a common Web-services-based infrastructure that supports grid- and management-based solutions'... While some observers pointed out that the Web services standards proposed by IBM, HP and the others differ from similar standards advanced by Microsoft and partners, Batchelder said all of the parties promoting Web services realize that 'everybody needs to do this'..." See details in the news story "Web Services Notification and Web Services Resource Framework."
[January 20, 2004] "WS-Resource Framework:Globus Alliance Perspectives." By Ian Foster [WWW] (Argonne National Laboratory / University of Chicago / Globus Alliance). Presentation January 20, 2004 at GlobusWORLD 2004. See especially slide #9, "From OGSI to WSRF:Refactoring and Evolution." "... Despite enthusiasm for OGSI [Open Grid Services Infrastructure (OGSI) Version 1.0], adoption within Web community turned out to be problematic: Too much stuff in one specification, does not work well with existing Web services tooling, Too 'object oriented'. The solution: WSRF partitions OGSI version 1.0 functionality into a family of composable specifications, tones down the usage of XML Schema, and makes an explicit distinction between the 'service' and the stateful 'resources' acted upon by that service..." [source .PPT, cache]
[January 20, 2004] "Web Services Notification and Web Services Resource Framework." An announcement from Akamai, The Globus Alliance, HP, IBM, Sonic Software, and TIBCO describes the release of three new specifications providing a scalable publication/subscription messaging model and the ability to model stateful resources using Web services. The new WS-Notification and WS-Resource Framework are designed to integrate Grid and Web services standards, and represent "a common, standards-based infrastructure will be available for business applications, Grid resources and systems management." Stateful resources are "elements that can be modeled including physical entities (such as servers) to logical constructs (such as business agreements and contracts). Access to these stateful resources enables customers to realize business efficiencies including just in time procurement with multiple suppliers, systems outage detection and recovery and Grid-based workload balancing." Web Services Notification as presented in WS-Notification "can automatically trigger an action in the IT infrastructure once certain criteria have been met. This can include suppliers automatically being notified to bid to replenish inventory once current inventory drops to a set level. Several suppliers can be notified of this depletion in inventory and WS-Notification can be set up so that only the supplier with the best bid fills the order." The WS-Resource Properties document "defines how data associated with a stateful resource can be queried and changed using Web services technologies. This allows clients to build applications to efficiently read and update data associated with resources, such as contracts, servers or purchase orders." The WS-Resource Lifetime document provides a means for the user to "specify the period during which a resource definition is valid. For example, WS Resource Lifetime can automatically update suppliers from all systems once contracts or service level agreements expire, or deleting products from inventory systems that are no longer being manufactured."
[July 22, 2003] "Web Services and Sessions." By Sergey Beryozkin. In O'Reilly WebServices.xml.com (July 22, 2003). "Web services are becoming an important tool for solving enterprise application and business-to-business integration problems. An enterprise application is usually exposed to the outside world as a single monolithic service, which can receive request messages and possibly return response messages, as determined by some contract. Such services are designed according to the principles of a service-oriented architecture. They can be either stateless or stateful. Stateful services can be useful, for example, for supporting conversational message exchange patterns and are usually instance or session-based, but they are monolithic in the sense that the session instantiation is always implicit. In general, a service-oriented approach (simple interactions, complex messages) may be better suited to building stateful web services, especially in the bigger B2B world, where integration is normally achieved through an exchange of XML documents. Coarse-grained services, with their API expressed in terms of the document exchange, are likely to be more suitable for creating loosely coupled, scalable and easily composable systems. Yet there still exists a certain class of applications which might be better exposed in a traditional session-oriented manner. Sometimes a cleaner design can be achieved by assigning orthogonal sets of functionality to separate services, and using thus simpler XML messages as a result. Such web services are fine-grained... If you believe that for a particular use case a fine grained design can result in a better interface, and that a reasonable compromise with respect to those problems can be achieved, then such a route should at least be explored. It is likely we'll see some standardization efforts in this area of state and resource management in the near future. Meanwhile, this article will look at ways of building stateful web services. In particular we highlight different ways of defining service references and identifying individual sessions..."
[July 2003] " Web and Grid Services: Architectures and Technologies." By Savas Parastatidis. 43 pages/slides.