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 20:37:43 UTC