- From: Eric Johnson <eric@tibco.com>
- Date: Mon, 28 Jul 2008 14:57:42 -0700
- To: "TALBOT Jacques (TJA)" <Jacques.TALBOT@teamlog.com>
- CC: "public-soap-jms@w3.org" <public-soap-jms@w3.org>
Hi Jacques, Leaping into the fray, without having talked with others recently about the subject, let me see if I can give you some background as to where we are now.... TALBOT Jacques (TJA) wrote: > * Title - is WS-Addressing irrelevant to "SOAP over JMS"? > There's probably some relevance. WS-Addressing comes along for the ride with some specifications - WS-MetadataExchange, WS-ReliableMessaging, WSDM, etc.... What I think we're open to is whether or not there is a use case for defining anything additional to the SOAP/JMS binding. If you've got specific use-cases in mind, that would help enormously. In the context of existing specifications, do you feel like the SOAP 1.2 Part 2 - HTTP binding should talk about WS-Addressing? My take is that the same question maps over to SOAP/JMS, and as such is not strictly in scope for the *binding* (although it is potentially of relevance to the working group, depending on the use cases). > * Description - for somebody outside of the working group, it looks like SOAP over JMS is closely linked to WS-Addressing, since JMS Queus are usually used for asynchronous MEPs. > That's tricky. From my perspective, there are two heavily overloaded concepts here: "asynchronous", and "MEP"s. I think the people involved in this specification have struggled with both. We certainly spent chunks of time wrestling over the difference between WSDL MEPs, and SOAP MEPs. As for the "asynchronous" part, is that referring to the code invoking message exchanges, or the message exchanges themselves? From what I know of how some of our customers use JMS, they very frequently use "request-reply" message exchanges over JMS - and from a coding perspective, it looks - for lack of a better word - "synchronous." Of course, what happens on the JMS side isn't. As you might have guessed, we intentionally do not mention WS-Addressing. > However, search the WG mailing list, and you do not find a single insantce of WS-Addressing. How come? possibly this has benn discussed on pthe WG private liste, but the spec says nothing about WS-Addressing being a non-goal. > The W3C working group has not existed for very long. Many of the vendors involved have been looking at standardizing SOAP over JMS for some number of years now. We did indeed have numerous discussions among those vendors before this went public at the W3C. > * Justification - Usually, you want to use SOAP over JMS for Asynchronous Request Reply MEPs with some guaranteed quality of service. Because SOAP/http is not enough in some situations. Asynchronous is the key word, because usually, for synchronous MEPS, it is easier to recover from the failures at the application level. (It is not a coincidence that MQseries and the likes are both asynchronous and reliable) > As you have identified, JMS provides different qualities of service. As far as I can tell, a user of the SOAP/JMS specification can take advantage of those capabilities without any changes to the spec as it currently stands. > Therefore, at the SOAP level, it becomes necessary to get a Reply-Port naming scheme and a Correlation-ID, which is what WS-Addressing porovides. JMS queues provide the same kind of artifacts (AFAIK). So the spec should define some mappings between the WS-Addressing and the JMS artifacts. > Since JMS natively provides for a client to specify a "reply-to" destination, I'm not readily thinking of any request-reply exchange where the "wsa:replyTo" header needs to be anything other than "anonymous", at least when you're using only JMS. If you're crossing transfer protocol boundaries (JMS to HTTP, for example), you can simply use a standard WS-Addressing header, as already defined. Perhaps you're thinking of a failure scenario that I don't see or understand? > * Proposal - evolve the WG goal to : "SOAP + WS-Addressing over JMS"; as is, the specification is lagging versus the (slowly progressing) state of the art in Web Services (see wstf.org for example) and therefore of limited interest (IMHO). > I'm fairly certain that the working group would happily look at additional use cases, but we'd need those use-cases spelled out clearly. > Kind regards to the W3C community for their good job > And thank you for your feedback. A bunch of us have been working on this specification for a *long* time - I'm glad to see interest in it. -Eric Johnson
Received on Monday, 28 July 2008 21:58:01 UTC