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

[Rex Brooks <rexb@starbourne.com>]

At 9:15 AM -0500 1/13/04, Farrukh Najmi wrote:
>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.
>

Unfortunately, after 2 years of development work, before it was 
brought into OASIS EM, it is not feasible to retrofit so many 
interests, and we are now in the final stages before submission to 
OASIS for a vote, or else another 30-day public comment period.

>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/

Yup. CAP 1.1 might benefit from integrating the ebXML Registry 
subscription model, and I will mention it when the appropriate time 
comes.

I'm not sure that WSRP TC would be interested, since it is a bit more 
specialized, but it's a thought.



>Thank you.
>
>--
>Regards,
>Farrukh

Ciao,
Rex
-- 
Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com
Tel: 510-849-2309
Fax: By Request