Re: Spec anomalies on targetService ?

Hi Phil,

Phil Adams wrote:
> 
> I agree with Eric that targetService should be only in the SOAP/JMS
> binding spec and that it should be specified in the endpoint location
> URI and not in the WSDL (other than the port's soap:address "location"
> attribute).
> 
> There's something that I've been curious about for a while...    In an
> HTTP endpoint location URI, the url pattern (i.e. the part after the
> context root - http://myhost:80/MyContextRoot/
> <http://myhost/MyContextRoot/>*services/MyServicePort*) is used to
> identify the port component that the request is intended for.     Within
> the JMS endpoint location URI, the targetService property serves the
> same purpose (more or less) as the url pattern in the HTTP case, but yet
> the targetService property is optional in the URI.    I'm not suggesting
> that we make it required or anything.  I guess I'm just curious how a
> particular vendor runtime would be able to determine which port
> component the request is intended for if the targetService property is
> not specified?    I know this was something that I struggled with when
> implementing SOAP over JMS in our WebSphere product.     Of course, if I
> want to put in place a restriction that only one port component is
> allowed per application module, then it's not an issue, but that
> restriction would be absurd :)
> 
> Does anyone have an idea how the request could be properly targetted to
> the correct port component *without* specifying the targetService property?
> 

At least in theory, there are a wide variety of techniques for
dispatching SOAP requests, some of which depend on the type of SOAP
binding in use.  Some examples:

 * Look at the "action" (SOAP 1.2) or "soapAction" (SOAP 1.1) value - it
may be unique across the services at a given endpoint.

 * Examine the child element of the SOAP Body element.  If you're using
RPC/lit binding, this will tell you the operation name, and probably as
a consequence the service.

 * (Proprietary) Expected SOAP message headers

 * WS-Addressing message properties - wsa:To, for example

 * non-SOAP transport properties - such as custom defined JMS headers,
or requesting host IP address or DNS name (for HTTP SOAP)

In my opinion, the dispatch problem is both a "feature", and a "bug" of
SOAP.  It is a "feature" in that it has left a problem that cannot be
solved in the abstract to a higher level.  It is possibly a bug in that
if SOAP just mandated a particular (narrow) approach, it might
ironically have made everything downstream of that easier, and thus made
SOAP more inter-operable.

-Eric.


> 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:  Eric Johnson <eric@tibco.com>
> To:  Peter Easton <peaston@progress.com>
> Cc:  public-soap-jms@w3.org
> Date:  10/07/2008 03:38 PM
> Subject:  Re: Spec anomalies on targetService ?
> 
> 
> ------------------------------------------------------------------------
> 
> 
> 
> 
> Hi Peter,
> 
> Curious.  From my perspective, the specification is correct.
> 
> Peter Easton wrote:
>> Just so we can track this separately.
>>
>>  
>>
>> I noticed going through the binding spec that Section 2.2.3 notes that
>> soapjms:targetService is marked “optional in IRI”. If I recall Eric’s
>> conversations correctly, I believe that this is intended a WSDL only
>> extension. The IRI spec does not mention the targetService, so something
>> is at least inconsistent.
>>
> 
> Perhaps my statement was unclear, but what I was trying to say is that
> targetService is specific to the SOAP/JMS binding spec.  It is not
> intended as a WSDL extension, but is only intended for placement in the URI.
> 
> It exists to provide a corollary to HTTP URLs. For a somewhat strained
> analogy  Imagine a servlet container is hosting a web application.
> Within that level, there may be one or more servlet endpoints that are
> capturing URLs within the context of that web app.  Within that servlet,
> there may be additional discrimination based on the URL.  That is, to a
> J2EE web application, the URL (somewhat simplistically) logically breaks
> down like:
> 
> ${host}/${webapp_ctx}/${servlet_path}/${service}
> 
> With my somewhat strained JMS analogy, supposing a service listens on a
> queue - the logical view of the queue looks like:
> 
> ${queue}
> 
> To restore some ability to share the same endpoint for multiple
> services, we add the targetService back in, and now the logical view of
> the URL looks like:
> 
> ${queue}?targetService=${service}
> 
> 
>>  
>>
>> Also note that targetService is missing from the list of WSDL extensions
>> in 3.6.
>>
> 
> I don't believe it is "missing", since I don't think it is supposed to
> be there.
> 
> -Eric.
> 
> 
> 
>

Received on Tuesday, 7 October 2008 22:01:41 UTC