RE: RE : WS-Addressing

Thanks to all for taking care...
As we all know, when a question is well articulated, it is half of the answer.
Unfortunately, I am not able to articulate well my precise question :-(  Anyway ...

I believe the Primer is a very  good place to provide some guidance on these topics.

So I will explain my problem and leave to you finding of the solution. I am not technical enough nowadays to go in the nitty gritty details.

We need to program at a WSDL/SOAP level both synchronous and asynchronous Request Reply MEPs.
- Synchronous RR is just an RPC;
- Asynchronous RR is asynchronous at the protocol level (as opposed to WSC toolkit level asynchrony) - with http, the reply travels on a different http connection than the request; probably with a JMS binding, there is not such a distinction since there is a Reply Queue in all cases.

Notice I am not using the WSDL or SOAP MEP names, because honestly, outside of the W3C spec writers, nobody ever use these notions.

For asynchronous, we use WS-Addressing to specify:
1 - Reply and Error ports  (with wsa:Anonymous to specify a specific "reply on http backchannel" case)
2 - Correlation IDs

So this is my programming universe. Ideally, I would like to be independent of the underlying bindings, be them http or JMS. But "protocols are leaky abstractions" unfortunately, so this is almost impossible.
So let's try to minimize the leaks.

At the binding level, JMS provides queues and correlationID abstractions.

My gut feelings, that I am not able to substantiate with technical statements, is that if there is no specification on how the WSA level abstractions (ports and ID) and the JMS level abstractions (Queues and ID) are related (or unrelated), the vendors will implement in their preferred ad-hoc way and not only will the protocol leak into the programmer's code, but also the toolkit will leak.

This is already the case to-day if you try to program asynchronous Request Reply with SOAP and http.
Axis2 and CXF and WebSphere and WebLogic all behave their own specific way!

If you try to program asynchronous RR with (for example) SOAP on JMS on WebSphereMQ, you have no WS-Addressing but "the addressing and correlators of Mr. WebSphere MQ", right up there in your SOAP code. How elegant! This is not to blame IBM, I believe other vendors do the same, but I do not have the smoking gun in their case :-)

So my plea to the SOAP on JMS WG is: do not reiterate the "http binding" WG errors.
If you try to articulate in the primer how the poor soul will program the above MEPs, it will help.
People want SOAP on JMS not for the fun, but generally to get asynchronicity and Quality of Service. Otherwise, http is good enough and more ubiquitous. So just delineating in the primer that asynchronous at the SOAP level is not the same that asynchronous at the transport (JMS) level will make the picture less fuzzy.
So, you have to address WS-Addressing and also WS-RM (more fun :-)

I understand the temptation to brush this dust under somebody's else carpet, (or not to drink this chalice, if you prefer another religious metaphor :-) but if you succumb to this temptation, how can users take the W3C specs as a help rather than a hindrance?

Well, enogh said, that was my last attempt to clarify my needs, which I believe are of general interest to many, as Nathan questions show.

Thanks anyway for your time and efforts

Jacques Talbot - Teamlog 10 rue Lavoisier - 38330 Montbonnot
Tél: 04 76 61 37 12  Mél:
Tél. mobile 06 07 83 42 00

-----Message d'origine-----
De : Glen Daniels []
Envoyé : vendredi 15 août 2008 13:39
À : Nathan Sowatskey
Cc : TALBOT Jacques (TJA);;
Objet : Re: RE : WS-Addressing

Hi Nathan:

Let me turn this around a bit - can you please explain (this is for Jacques/Mark too) exactly what you think should be covered in the spec?
  Mark's original message said "clear direction on what to do when using WS-Addressing header with SOAP/JMS"... We'll certainly cover that to some extent between the primer and the test suite (which will absolutely cover a variety of cases), but I'm not clear on just what you think should be included.  Keep in mind that Addressing says "here's how you use these headers/properties to bind to various SOAP MEPs", and our binding (just like the HTTP binding) says "here's a binding that offers SOAP MEPs".

Tell us what the problem is and we'll try to get it solved, or point you in the right direction at least.


Nathan Sowatskey wrote:
> Hi all
> The question of how WS-Addressing relates to the SOAP/JMS binding is
> also important to us, both at Cisco NMTG for our use of WSDM, and at
> the TMF TIP for reasons related to mapping MTOSI headers to WS-Addressing.
> I can understand the WG's desire to avoid having to specify this in
> the SOAP/JMS the binding, but I hope that this does not cause
> ambiguity as a consequence. I don't believe that a FAQ entry is
> sufficient, though that could be a useful first step.
> I expect that a this would require a normative addendum, which perhaps
> we could start planning for now?
> Many thanks
> Nathan
> On 06/08/2008 16:13, "TALBOT Jacques (TJA)"
> <>
> wrote:
>> +1
>> Great, the cavalry to the rescue, two of us are now asking !
>> The FAQ "disclaimer" does not sound as a very exciting solution.
>> This is like the classical bureaucracy story: you ask Bureau 23, they
>> tell you, it is not us, ask bureau 54 and so on and so forth :-)
>> Jacques
>> ___________________________________________
>>  Mobile: 06 07 83 42 00
>> De : []
>> de la part de Mark R Maxey [] Date d'envoi :
>> mercredi 6 août 2008 11:46 À : Objet :
>> WS-Addressing
>> I've tried to follow the WS-Addressing discussion, so I'm sorry if
>> I'm rehashing old ground ...
>> Did anyone consider leaving some properties abstract in this document
>> and creating other documents with concrete mappings to JMS headers &
>> WS-Addressing?  Is there going to be a addendum or note that speaks
>> to WS-Addressing?
>> I'd like to see clear direction on what to do when using
>> WS-Addressing header with SOAP/JMS.  There's ambiguity and overlap to
>> be addressed.  WS-Addressing also includes some metadata not available via JMS, e.g., FaultTo.
>> Perhaps I'm misguided, but I thought the beauty of SOAP was that the
>> same message could be sent over HTTP or JMS without modification.
>> That concept is broken if one is forced to use protocol specific
>> metadata.  I would like to see a SOAP/JMS or SOAP/HTTP where
>> properties of protocols are configured via the WSDL,  web services
>> infrastructure "binds" to protocols at the transport layer, and the
>> creation and processing of message content is 100% based on the XML
>> SOAP payload.  This allows web service implementations to minimize the amount of protocol specific code.
>> Cheers,
>> Mark Maxey

Received on Monday, 18 August 2008 08:46:04 UTC