Re: [regrep] Fwd: Re: [emergency] BEA, Microsoft,and Tibco Release WS-Eventing Specification

[Farrukh Najmi <Farrukh.Najmi@Sun.COM>]

Rex Brooks wrote:

> Excuse the non-sequitur post, but I wondered if anyone on this list 
> might be interested in this development?

Hi Rex,

As you probably know that ebXML Registry has had a Content-based Event 
Subscription and Notification feature since version 2.5. At the time we 
wrote version 2.5 there no Event Subscription/Notification standards we 
could build upon. What we built is actually quite flexible and powerful. 
Ad hoc queries in SQL and XML filter query syntax may be used as 
selectors within a Subscription and determine whether an event matches 
the subscription. If events match one or more subscriptions they are 
delivered to a listener web service endpoint and/or an email endpoint.

I do not see any new functional value that this Eventing spec brings to 
to ebXML Registry. In fact it is lacking many of features of ebXML 
Registry Event Notification. Technical issues aside, I also have 
significant issues with any specification that is is not being developed 
in an open  standards process and tightly coupled with many other 
similar closed specs.

>
> It's billed as a substrate allowing more than simple http 
> request-response by using ws-addressing to decouple message from 
> transport. I thought that was already possible, but maybe I missed 
> something.

Indeed ebXML Messaging has been doing that for nearly 4 years now.

> What do we really need that registries and http request-response 
> doesn't do while very effectively restraining clutter and scalability 
> issues in important channels (not to mention enforcing security 
> considerations)?

ebXML Registry can function very well as an event service for web 
services today. However, architecturally it makes sense to factor out an 
event service specification to stand on its own (with few foundation 
level dependencies such as SOAP and WSDL). Such a Service would be be 
similar in its architecture to an Event Bus (e.g. Java Messaging 
Service), and would be used by web services to publish events and 
subscribe to events. It should offer a choice in Quality of Service 
(QoS) such as "fire and forget", "At most once delivery" or "once and 
only once delivery".

> Also, shouldn't "eventing" be reserved to processes that have 
> definite, understood, triggered response processes? An interesting 
> event sounds a bit like a distraction more than an important event 
> with immediate important consequences.

IMO, any service could generate events and any service could be 
interested in any event. What's an important to one service may be of no 
interest to another.

For the Emergency Management TC I suggest they look at ebXML Registry 
content-based event notification. I should clarify that ebXML Registry 
does not depend upon any other ebXML specs and may be used by any type 
of client.

I would be glad to discuss use of ebXML Registry in emergency management 
if there is interest. As you probably already know a recent presentation 
on ebXML Registry and emergency management may be found here:

http://www.oasis-open.org/presentations/

Thank you.

-- 
Regards,
Farrukh