Re: Spec anomalies on targetService ?

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

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.