Unified Protocol Proposed for Java, .NET "Events"

A leading group of tech experts from Java, .NET and the middleware sector have gotten together a proposal called WS-Eventing for helping make it easier for architects and devs to integrate web services components into high-performance applications. IDN looks why devs shouldn't be worried about an apparent competing plan from IBM, and how details of the XML/SOAP-based plan, will help ISVs mask the complexity of SOA integration projects.

Tags: WS-Eventing, Web Services, Notifications, Subscriptions, IDN, Kiger, Microsoft,


A leading group of tech experts from Java, .NET and the middleware sector have gotten together a proposal for helping make it easier for architects and devs to integrate web services components into high-performance applications.

The proposal, dubbed WS-Eventing has been offered by BEA Systems, Microsoft and Tibco.

[While IBM has proposed a similar spec this month, WS-Notification, devs should not feel the specs will compete or confuse the issue, Ronald Schmelzer, a web services analyst with Zapthink told IDN. For more of his comments on the IBM/Microsoft landscape, see "Conflicts Between WS-Eventing and WS-Notification?" section below.]

At its core, WS-Eventing proposes a new cross-platform protocol that would allow web services to subscribe to (or accept subscriptions) for event notifications via SOAP and XML messaging. Many complex, multi-platform applications and web services, such as customer ordering, stock trading or inventory management/supply chain are more than click-and-go applications -- they are on-going processes that reach a certain level and then "trigger" a "response" (or a follow-on action) to a certain level of event.

WS-Eventing also looks to fill in the blanks for describing a now-missing mechanism that would enable service-oriented architectures (SOAs) to "register" their interest in being notified of events and/or triggers that would affect their operation.

"It's a small piece of the puzzle, but an important piece," John Kiger, BEA program manager told IDN. The key is that WS-Eventing would leverage current (and new) web services standards for implementing the two-way communication between applications and objects. Among key specs WS-Eventing could/would use, Kiger said, are WS-ReliableMessaging, WS-Policy and WS-Transaction.

Another key element of WS-Eventing is its platform independence, Peter McKiernan, lead product manager for Microsoft's platform strategy group told IDN.

"We're looking to make sure that WS-Eventing will work for all environments. The worst thing that could happen would be to have a different WS-Eventing for enterprise, another for mobile and another for devices," McKiernan said. "So, we want to define a broad interoperability level."

Adding to this theme, Brad Lovering, one of the Microsoft engineers who helped to create WS-Eventing, told IDN, "Based on industry feedback, WS-Eventing was created…as a straightforward general purpose eventing scheme for vertical solutions to be built upon [and] was designed to be a completely generic building block, scaling from small device to enterprise scenarios."

Inside WS-Eventing: Anatomy of Setting Open Triggers
In specific, WS-Eventing 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.

In particular, WS-Eventing looks to
  • Define means to create and delete event subscriptions;
  • Define expiration for subscriptions and allow them to be renewed;
  • Define how an event sink can determine which subscriptions it is receiving notifications for; and
  • Define how one event sink can subscribe on behalf of another.
  • WS-Eventing provides formal models for its new protocol in the XML Schema and WSDL files, and supports SOAP 1.1 and SOAP 1.2 envelopes.

    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.

    "WS-Eventing is important is because different systems have their own proprietary ways of defining events and sending notifications. WS-Eventing standardizes both," Ronald Schmelzer, analyst with Zapthink, told IDN. "This would allow a TIBCO system to send notifications to a .NET system, for example. So, somewhat straightforward, but still nonetheless incredibly important for the new class of standards-based, asynchronous, loosely-coupled integration that Web Services and SOAs represent."

    So, how much might WS-Eventing complicate the lives of devs trying to build Java-to-.NET web services?

    The good news, if all goes well, is not at all, BEA's Kiger told us. "WS-Eventing is a structure that in many cases devs will not have to interact with directly. Instead, they would use let's say declarative operations that are visual drag-and-drop or property sheet check boxes that result in effect to have framework implement the underlying infrastructure, EJB code or WS-Eventing code," he added. In BEA's case, for example, Kiger said, the WebLogic Workshop tool for BEA's WebLogoc J2EE application server would take over much of the bare coding work, Kiger said, and he expects that the architecture of WS-Eventing would allow Microsoft and other .NET vendors to offer a similar abstraction layer.

    Conflicts Between WS-Eventing and WS-Notification?
    Meanwhile, IBM presented its own approach for handling event notification in a web service, called WS-Notification. While many in the press have painted this divergence between IBM and Microsoft as reason for dev concern -- and confusion, analysts disagree.

    "IBM found that their priorities were for allowing brokers to be present between the event publisher and subscriber, and in addition to support management of the notifications and end points, Zapthink's Schmelzer told IDN. "Also, IBM wanted to support their Grid initiatives that required notifications to make it work In the long term, companies won't be faced with having to implement both WS-Eventing and WS-Notifications to make their cross-industry pub/sub work."

    Meanwhile, for its part, it looks like Microsoft wants to avoid any semi-proprietary approaches. Until WS-Eventing, there has been "no standard way" to achieve this interaction, McKiernan said. "Now, we're providing an open invitation for developers to review our suggestion in the form of a proposed specification, and then we want to get feedback from them." he added. "The effort is all about designing an open spec that works for all environments."



    back