- From: TALBOT Jacques (TJA) <Jacques.TALBOT@teamlog.com>
- Date: Wed, 6 Aug 2008 16:13:57 +0200
- To: "public-soap-jms@w3.org" <public-soap-jms@w3.org>
- Message-ID: <B9015734-07D9-4CF4-88C8-7E4616B5D055@mimectl>
+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 Wednesday, 6 August 2008 14:14:35 UTC