Another WS-Star candidate for Event Driven Architecture - WS-Eventing

In my last post I had a look at Web Services Notification (WSN). In this post I'll see what Web Services Eventing (WS-Eventing) has to offer. Where WSN is a formal OASIS Standard Web Services Eventing is currently only a Member Submission to W3C back in March 2006. The list of vendors behind the specification are most of the big players like for WSN with the big difference that Microsoft is participating.

The specification tries to meet the following requirements:

• Define means to create and delete event subscriptions.
• Define expiration for subscriptions and allow them to be renewed.
• Define how one Web service can subscribe on behalf of another.
• Define how an event source delegates subscription management to another Web service.
• Allow subscribers to specify how event messages should be delivered.
• Leverage other Web service specifications for secure, reliable, transacted message delivery.
• Support complex eventing topologies that allow the originating event source and the final event sink to be decoupled.
• Provide extensibility for more sophisticated and/or currently unanticipated subscription scenarios.
• Support a variety of encoding formats, including (but not limited to) both SOAP 1.1 [SOAP 1.1] and SOAP 1.2 [SOAP 1.2] Envelopes.

I haven't done a formal comparison but there seems to be quite a overlap between Web Services Notification and Web Services Eventing.

An attempt for convergense

It isn't the first time that we see two competing standards in the WS-Star stack, not that it makes it any better. I found that at the same time that the specification was submitted to W3C, the four companies Intel, Microsoft, IBM and HP put out a a letter of intent with the title "Toward Converging Web Service Standards for Resources, Events, and Management":

HP, IBM, Intel and Microsoft plan to develop a common set of specifications for resources, events, and management that can be broadly supported across multiple platforms. The parties will do this by building on existing specifications and defining a set of enhancements that enable this convergence. In many scenarios, vendors and customers building solutions using Web services will find that the existing specifications support their scenarios. Vendors and customers may use the new specifications and functions when needing the common capabilities.

The full text [PDF] can be found on intels website or in googles cache from Microsofts website. To my knowledge this never materialized, but maybe this is what turned up as a new working group at W3C.

Web Services Resource Access (WS-RA)

Just as I had concluded that WS-Eventing had stranded at W3C I found that W3C in november 2008 launched the Web Services Resource Access Working Group, and from the charter the scope is:

The Web Services Resource Access Working Group is chartered to standardize a general mechanism for accessing and updating the XML representation of a resource-oriented Web Service and metadata of a Web Service, as well as a mechanism to subscribe to events from a Web Service. The following list of features is intended to focus the work of the Working Group and ensure its timely completion:

1. The definition of basic Create, Read, Update, Delete (CRUD) operations that provide capabilities to create, read, update and delete a Web Services XML representation and the binding of these operations to SOAP.
2. A mechanism to allow a requester to retrieve metadata, or references to metadata, related to a Web Service and a mechanism to allow embedding of such metadata, or references to such metadata, in an Endpoint Reference (EPR). The defined capability must provide for retrieval and embedding of specific items of metadata such as WSDL, XML Schema and WS-Policy. The referencing of metadata must allow for both EPR or URL style references.
3. The definition of Web service operations (e.g. Enumerate, Pull, etc…) to enable a consumer to request and manage an enumeration context, and retrieve data items from an enumeration context for a data source. These operations must define details of SOAP messages for the request and response as well as one or more filter dialects to select the data that would be sent to the consumer. The ability to work efficiently with large datasets is important.
4. The definition of Web Services operations (e.g. Subscribe, Unsubscribe, etc…) to create and manage subscriptions to events that are delivered via Web Services.
   1. The definition of one or more filter dialects, such as XPath, that can be used in subscriptions to indicate interest in messages with specific content.
   2. Mechanisms to allow a subscriber to specify the means by which an event is delivered and the definition of a push-based delivery mode.
5. A mechanism by which a Web Service can advertise, through its metadata, such as WSDL and WS-Policy, the capabilities it supports from among the features defined by the Web Service Resource Access specifications.

The thing that jumps into my eyes is how RESTfull this sounds!

This high speed WG i supposed to deliver the recommendations in little more than a year (June 2010), which in quite fast in terms of standarization speed. The work will build on the following submission:

• Web Services Transfer (WS-Transfer)
• Web Services Resource Transfer (WS-RT)
• Web Services Enumeration (WS-Enumeration)
• Web Services Metadata Exchange 1.1 (WS-MetadataExchange)
• Web Services Eventing (WS-Eventing)

The current editors draft of WS-Eventing is available online as promised. Judging from the issues related to WS-Eventing convergence doesn't seem to be on the agenda.

Interesting enough IBM has part in both specifications and their standpoint can be read in a mail from Steve Holbrook to the W3C maillist to show their support for WS-RA, "Re: Standardization of WS-Eventing":

IBM remains committed to use of the OASIS Standard WS-Notification 1.3 as the interoperability standard for enabling a broad range of applications that include publish/subscribe and event notification in the context of business and complex event processing scenarios. However, we are supportive of the W3C standardization of WS-Eventing because we appreciate that some in the Web Services community are using it in certain domains such as device management and we are interested in ensuring that such a standard compose effectively with other Web services specifications including WS-Notification.

Conclusion

I'm not in a position to really conclude anything except from the obvious that I would have preferred to have one widely supported specification instead of two lightly adopted ones. Ih this I agree with Gartners conclusion from back in 2006, "WS-Notification Standard Ratified by OASIS Still Needs Work";

The delay in reconciling WS-Notification and WS-Eventing shows that the Web services standardization process has lost momentum. Standards have remained static for the past year, permitting only primitive interoperability.