RE: RE : WS-Addressing

Jacques,
You seem to be mixing programming model issues with issues of the 
underlying runtime.

>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 :-)

What client programming model are you using in this situation?     I'm not 
aware of any asynchronous programming model on WebSphere MQ.
However, if you were to use the WebSphere v6.1 Web Services Feature Pack, 
then you could write a JAX-WS web service application that uses the 
asynchronous API provided by JAX-WS, and this would allow you to use an 
async request/reply MEP and you would be shielded from the details of the 
underlying transport (i.e. you wouldn't be dealing with correlation IDs, 
etc.).   You could simply use either the polling or callback mechanisms to 
handle the response.

If you are not using a programming model that provides for true 
asynchronous behavior (an example would be if you're using JAX-RPC one-way 
requests and trying to match up the "reply" with the "request") then of 
course, you're going to need to handle the async details since the 
programming model doesn't do that for you.   In that case, you might want 
to consider a programming model that *does* provide asynchronous support.

However, I don't think the shortcomings in the client programming model 
should be a reason to make the SOAP/JMS spec more than it is intended to 
be... that would confuse the issues more than it would clarify them, in my 
opinion.    I'm sure my SOAP/JMS WG colleagues will correct me if I'm 
wrong, but my opinion of the SOAP/JMS spec is that it is mostly intended 
to guide web service runtime vendors to enable them to provide a runtime 
that can interoperate with other runtimes when exchanging SOAP messages 
over JMS.       It does not, however, touch on the client programming 
model nor is it intended to.

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

You're right... there's no specification about the two correlation IDs, 
nor should there be.   They are separate and distinct, IMO.     The notion 
of a WSA Endpoint Reference (EPR) is, for the most part, 
transport-agnostic.   So even though you mentioned "ports", that is your 
view because you are using HTTP as your transport.     If you were using 
SOAP/JMS, then you would be talking about a "queue" instead.

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

But, it is not the intent of the SOAP/JMS spec to dictate how the user 
"programs the above MEPs".   That would be the responsibility of the 
client programming model that you have chosen to use (e.g. JAX-WS, 
JAX-RPC, etc.).
 
>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. 

Well, it's certainly true that async at the "SOAP level" (I assume you 
mean client programming model) is independent of the notion of async at 
the transport level.  I can think of a situation where an async transport 
(JMS) can be used to implement a synchronous request/response MEP in 
JAX-RPC, for example.

>So, you have to address WS-Addressing and also WS-RM (more fun :-)

Sorry, I don't agree that the SOAP/JMS spec should address WS-Addressing 
(no pun intended).    And I certainly don't think we should talk much 
about WS-RM other than to perhaps say that you probably don't want to use 
WS-RM in conjunction with SOAP/JMS.   The fact that messaging engines 
already provide various levels of reliability means that you probably 
don't want or need the added overhead of using WS-ReliableMessaging. WS-RM 
is mainly intended for use on un-reliable transports (e.g. HTTP).

Phil Adams 
WebSphere Development - Web Services
IBM Austin, TX
email: phil_adams@us.ibm.com
office: (512) 838-6702  (tie-line 678-6702)
mobile: (512) 750-6599




From:
"TALBOT Jacques (TJA)" <Jacques.TALBOT@teamlog.com>
To:
"public-soap-jms@w3.org" <public-soap-jms@w3.org>, 
"tip-framework@lists.tmforum.org" <tip-framework@lists.tmforum.org>
Date:
08/18/2008 03:47 AM
Subject:
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: jacques.talbot@teamlog.com
Tél. mobile 06 07 83 42 00


-----Message d'origine-----
De : Glen Daniels [mailto:glen@wso2.com]
Envoyé : vendredi 15 août 2008 13:39
À : Nathan Sowatskey
Cc : TALBOT Jacques (TJA); public-soap-jms@w3.org; 
tip-framework@lists.tmforum.org
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.

Thanks,
--Glen

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)"
> <Jacques.TALBOT@teamlog.com>
> 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
>>
>> ___________________________________________
>> Jacques.Talbot@teamlog.com  Mobile: 06 07 83 42 00
>>
>> De : public-soap-jms-request@w3.org [public-soap-jms-request@w3.org]
>> de la part de Mark R Maxey [Mark_R_Maxey@raytheon.com] Date d'envoi :
>> mercredi 6 août 2008 11:46 À : public-soap-jms@w3.org 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
>>
>
>
>