coarsegrained: WS-Eventing spec released

« A Rose By Any Other Name | Main | WS-Notification feedback »

January 09, 2004

WS-Eventing spec released

I was very excited to see the WS-Eventing specification released this week. We've been looking for something just like this for a number of our purposes. As one example, the body of subscription request messages has just the things we need to specifying a content routing subscription:
- where to send content notifications (the content itself)
- where to send notifications of subscriptions ending
- when subscriptions should expire
- a method of specifying filters on the subscriptions

It also has, in the body at least, no baggage that we don't need. By contrast, we have seen other content routing systems require subscribing users to set up rules for the content routing first, and then allow users to register interest in those rules. This creates a manageability issue for subscribing users of having to either identify and search among existing routing rules, or follow a two step process of creating rules and then establishing subscriptions to them, an unnecessarily complex process. I'll be posting more on attributes of easy to use content-based routing later, and what content-based routing adds to the pure web services world that it doesn't have now. Suffice it to say in the meantime, that WS-Eventing has what is needed to do content-based routing subscription and notification.

This is very good news. But I also see a few flaws in the current WS-Eventing specification. WS-Eventing uses the WS-Addressing spec intelligently for several things:
- the endpoint references for content and subscription end notifications are of WS-Addressing EndpointReferenceType
- this includes use of WSA ReferenceProperties within those endpoint references that allows followon messages (subscription responses, content notification responses) must include in their message headers (literally without any surround WS-Addressing or WS-Eventing related header)
- to relate subscription requests and responses (and other request/response message pairs). Specifically responses will have a WS-Addressing RelatesTo header that matches the MessageID content of the request.

These uses make sense, and its great that we don't have to learn a one-off method for these capabilities (endpoint references, reference properties needed by requestors, and correlation of messages). But there remain some unexplained and sometimes inconsistent issues around WS-Eventing's use of WS-Addressing headers:
- Is use of the WS-Addressing headers actually required? It is implied by various aspects of the spec but not actually spelled out. There could be quite a bit of utility for many people to allowing these WS-Eventing conversations to take place via synchronous generic SOAP http requests, using only the SOAP Body content specified (though that content of course correctly uses types from the WS-Addressing spec).
- If use of wsa: headers is required, there is more information that needs to be nailed down in the spec. The spec currently says that wsa:RelatesTo in the header of SubscribeResponse, must be value of the wsa:MessageID of the corresponding request. It doesn't say anything about the wsa:To. Presumably (if use of wsa: headers is required) it must be the value of the wsa:ReplyTo of the request. If the SubscribeResponse is coming back in the http response from a synchronous SOAP request, then perhaps the wsa:To is not necessary. If it is necessary (and population of all wsa: headers is required), then the correct population of it should be described, if only for the sake of consistency.
- There is a dangling element definition called SubscribeTo that is not used anywhere in the schema. I suspect that this is because some method of identifying who to send subscription responses when not using WS-Addressing headers was originally planned. It would be necessary when you didn't have wsa: headers if you were asynchronously responding to a subscription request.

Overall, I think there is some value to allowing the exchange of these WS-Eventing messages (subscribe request/response, unsubscribe request/response, etc.) over generic SOAP non-WSA-supporting transports. This could be done by requiring a synchronous http exchange to effect them without having to do explicit correlation of RelatesTo/Message and To/ReplyTo elements. And yet we could still use the relevant WS-Addressing data types where they help (as noted above). Nevertheless, I can also live with required use of WS-Addressing headers or even a fullfledged WS-Addressing-capable transport (we'll be building a very early an implementation of such anyway). I just think that the WS-Eventing specification should be a little clearer in that case.

These reservations aside, WS-Eventing is a very exciting development. Beyond the fact that it is very good specification (I think the WS-* specs are actually getting better over time), by facilitating the creation of content routing services, it introduces for the first time to the web services world the capability of sending messages for which you do not know the recipient. This is a key building block to enabling rapid integration of many web services and applications around individual business events.

January 09, 2004 in Web Services Infrastructure | Permalink

Comments

WS-Eventing fits quite nicely with the previous WS-Adressing and WS-RM but I wonder why the
overall agenda remains "to be guessed between the lines".
During the last 18 months or so, the WS community is trying to reinvent a MOM with queues
and topics (to use a JMS vocabulary) and associated semantics once&only_once.

This is a very good objective since we need the MOM semantics (asynchronous, reliable) in
an interoperable standard open world (JMS is not so).
So now with WS-Adressing, WS-Eventing and WS-RM we have a decent interoprable MOM.

I think it would be much clearer for many people if this objective
was stated up-front, so that one can use some
existing mental model to understand where WS- is going.

In this context, it is a real problem that IBM decided to opt out
and also that "the other camp" esp. Sun and Oracle are not there since in this specific
case they have nothing to loose, (only to converge the two specs for reliability, these
two are really ridiculous).
For the other part of the WS battlefield, BPEL vs WSCI, long transactions ..., we can
understand that the two camps want to fight, and we, as users, can wait since we can live
without a standard for a while.

On the contrary, for what regards the "WS-MOM", we need this NOW to make serious
applications, so we need industry convergence. Let's convey this message to the big
players ...

What do you think?
--
[email protected] Teamlog - France

Posted by: Jacques Talbot | January 16, 2004 at 12:56 AM

Yes, I agree with your observation about the whole "building buses up from the ground up bit by bit" in the WS-* specifications. I'm not sure how bad this is. Microsoft (and IBM on other specifications) are pretty straightforward in the "layered approached to specifications" strategy. Its part of the reason behind forming the WS-I profiles for putting these things together. Perhaps we need a WS-I "multiparty integration profile"? It could include usage of UDDI, WS-Addressing, WS-Eventing, WSDL 2.0 Patterns 2.0?

I can't speculate on IBM's reason for not joining. But Mills was quite clear in a recent (December) interview that there may not be a lot more cooperation on future specs beyond what they've done so far. Obviously it would be even more surprising to see Sun and Oracle on it.

Posted by: Adam Blum | January 19, 2004 at 08:41 AM

Posted by: aol | July 31, 2007 at 02:41 AM

http://safekwm.iquebec.com/

Posted by: Markrstbv | August 22, 2007 at 07:10 PM

http://fepoemm.byethost13.com
http://oemmmsie.awardspace.com
http://iwoerikke.iespana.es
http://poseoiiem.iquebec.com

Posted by: Mardkomqhta | August 24, 2007 at 07:21 PM

small bussines loans
[url=http://www8.vjc.edu/NewSite/discuss/msgReader$20]irwin mortgage company[/url]
[url=http://www8.vjc.edu/NewSite/discuss/msgReader$21]coach handbag outlet[/url]

Posted by: loansIII | November 16, 2007 at 09:39 AM

[url=http://userpoint.2222mb.com/userpoint/crazy-train-bass-tab.html]james mickie screensaver[/url]

Posted by: hdfihfiosjkoIII | November 29, 2007 at 10:11 PM

comment6, online altace dreampharmaceuticalscom, 8OOO, altace hope trial, >:-(, altace memory, bty, lotensin altace, =PP, altace and arthritus, >:-O, generic drug for altace, nnoppz, altace drug side affects, opivsz, efecto secundario de altace 5mg, 802393, buy altace low cost, ljx, free altace side effect, 776319,

Posted by: jonn2 | July 08, 2011 at 12:59 AM

The comments to this entry are closed.

About

September 2005

Sun	Mon	Tue	Wed	Thu	Fri	Sat
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30

Blogs

Specs

Companies

Good Technology
open architecture for mobile access to enterprise data
My Wireservice
My newsreader.
ZapThink
very insightful writing on unsolved problems in web services
Center for Document Engineering
one of the few places really concentrating on how to do good document design
MindReef
I love the focus on value-added WSDL tools. Very important for schema-first approach to web services creation
Microsoft Advanced Web Services

coarsegrained

thoughts and observations from Adam Blum on web services and XML document-oriented development approaches and tools