WS-Eventing application view

[hbraun]

From the specs:

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. This specification defines a protocol for one Web service (called a "subscriber") to register interest (called a "subscription") with another Web service (called an "event source") in receiving messages about events (called "notifications" or "event messages"). The subscriber may manage the subscription by interacting with a Web service (called the "subscription manager") designated by the event source.
To improve robustness, a subscription may be leased by an event source to a subscriber, and the subscription expires over time. The subscription manager provides the ability for the subscriber to renew or cancel the subscription before it expires.
There are many mechanisms by which event sources may deliver events to event sinks. This specification provides an extensible way for subscribers to identify the delivery mechanism they prefer. While asynchronous, pushed delivery is defined here, the intent is that there should be no limitation or restriction on the delivery mechanisms capable of being supported by this specification.

The WS-Eventing specification defines the viewpoint of a web service client (EventSink)
towards a web service that emits events (EventSource).

I was wondering what an application viewpoint looks like.
Is it right to assume that applications emit JMS messages
and the subscription manager basically acts as a bridge
towards the the web service layer?

[thomas.diesler]

Yes, the subscription manager should be service that maintains a Map<URI, List> list of EPRs for every source URI. Any event source can use the subscription manager to send out events.

Maybe like this

@Session
public class MySLSB {

 @Resource
 SubscriptionManager subman;

 public void ejbTimeout()
 {
 subman.sendEvent(uriSource, objEvent);
 }
}

AFAICS, the spec talks about how a sink can register/renew/delete subscriptions, but does not talk about how a source would register with a manager. At this point of time event sources are not portable because there is no JSR defining a standard contract between the source and the manager

[hbraun]

It raises even more questions. Especially:

- Should durable subscriptions be supported?
- Do we need a persistent message store?

At a first glance, this doesnt seem to be too much an issue,
but when you start picturing possible application scenarios these questions do arise.

To me, it seems more natural to back the subscription manager by a JMS implementation.
On the web service side, we could use Map<URI, List> to map the EPR's,
whereas on the application side we could use Map<URI,Topic> to map each URI to a JMS topic.

This way we could solve the issues listed above by simply deferring those problems to the JMS server.

On the other hand, an event source could simply publish events through the JMS API.

[thomas.diesler]

No, the initial ws-eventing implementation should not be coupled to JMS in any way. The SubscriptionManager should be a general JMX service (which later needs to be migrated to a pojo service that runs on the microkernel).

Additional to the ws-eventing defined subscription model for eventink sinks (i.e. Subsribe, Renew, GetStatus, Unsubscribe, SubscriptionEnd) it should offer managed operations for event sources (i.e. create, start, stop, destroy)

An event source itself is an WS endpoint that event sinks can subscribe to. Later, when we have an implementation of the endpoint deployment API (see JSR-224) we can create event sources more elegantly. Initially, an explicit endpoint deployment with an endpoint impl that we provide is ok.

A JMS topic is just yet another event source. Initially it is acceptable when a MDB uses the SubscriptionManagerMBean API to send events. Later it might be useful to pipe JMS messages directly to the SubscriptionManager without the need of an additional MDB.

Lets have a whiteboard session about that, this is the greatest benefit of both of us beeing in Munich. It is well possible that I fail to understand your vision.

[starksm64]

There should not be a requirement for a JMS provider, but it makes little sense not to be able to leverage the JMS implementation to provide an implementation of the reliable semantics needed.