Re: RE : WS-Addressing

Hi all

Apologies for the abrupt silence. I am travelling at the moment.

My main concern would be to understand how the WS-Addressing headers map to
JMS headers.

I'll have more time to explore what I think the answer could look like when
I get home next week.

I do not think that the SOAP/JMS specification can or should address this,
but nor can I feel that this question can be ignored entirely.

Regards

Nathan


On 18/08/2008 19:13, "Phil Adams" <phil_adams@us.ibm.com> wrote:

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

Received on Monday, 18 August 2008 20:39:30 UTC