- From: Amelia A Lewis <alewis@tibco.com>
- Date: Mon, 1 Dec 2008 13:25:13 -0500
- To: Sanjeev_Dokiburra@ibi.com
- Cc: public-soap-jms@w3.org
Dear Sanjeev, I'm sorry to break in, here, but this is becoming rather odd. I (strongly) recommend that you (re-?)read, and understand, the specifications before beginning implementation. At present, your understanding of the SOAP (XMLP) specification, on which the SOAP/JMS specification is based, seems to be insufficient to the task. My recommendation is that you attempt to implement SOAP over HTTP, for which there are public tools and endpoints available, to verify your comprehension and the interoperability of your tool, and then use that code (and understanding) in the extension to SOAP/JMS. On Mon, 01 Dec 2008 16:20:33 +0000, Sanjeev_Dokiburra@ibi.com wrote: > 1. So I guess the value of soapAction attribute in the WSDL has to > be used while constructing SOAP service call as below(even though it > is using JMS transport). Please correct me if I am way off base. You are way off base. The SOAPAction attribute does not designate an endpoint; in terms that are now considered obsolete, the value of the attribute is a uniform resource *identifier*, not a uniform resource *locator*. That is, this attribute contains a string (xsd:anyURI is best defined as "not a URI in any meaningful sense of the term") which identifies the bit of code to be invoked on the server. It is not an endpoint. It is a piece of information used (by the service side) to select a code path for processing (or not so used, depending on the architecture of the service side). > 2. I would like to test my client by connecting to a JMS > webservice. Wondering if there is any webservice exposed with jms > transport, for public usage. So far as I am aware, no one has completed implementation to the point of deploying public services for interoperability testing. The SOAP-JMS working group has now delivered our Last Call Working Draft, so this may change at any moment, as we enter the interoperability/testing phase, looking for problems in our specification. I would recommend that you first test your understanding/implementation of SOAP by finding similar resources for SOAP/HTTP, and insuring that everything works as expected (for instance, the above misapprehension of the function of SOAPAction might have been obviated by implementing in that environment). Amy! -- Amelia A. Lewis Senior Architect TIBCO/Extensibility, Inc. alewis@tibco.com
Received on Monday, 1 December 2008 18:26:00 UTC