-
1. Re: WS-Eventing application view
thomas.diesler Nov 22, 2005 3:20 AM (in response to hbraun)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 -
2. Re: WS-Eventing application view
hbraun Nov 22, 2005 5:23 AM (in response to 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. -
3. Re: WS-Eventing application view
thomas.diesler Nov 22, 2005 5:57 AM (in response to hbraun)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. -
4. Re: WS-Eventing application view
starksm64 Nov 22, 2005 10:54 AM (in response to hbraun)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.