RE: Spec anomalies on targetService ?

Hi Eric,

Thanks for the explanation. This all makes sense.

As you point out, targetService is SOAP/JMS specific so it isn't
described in the "Shared Parameters" section of the IRI spec. It is
allowable by the IRI spec under the "Custom Parameters" section. 

The fact that the targetService appears as a query parameter threw me
off a little when looking the WSDL section, but given your analogy to
HTTP path segments now starts to make sense.

I'd suspect that SOAP Action would be the primary dispatching mechanism
(there are WS-A prescriptions to define wsa:Action and hence can equally
apply to SOAPAction for dispatching to operations.

Having an alternative dispatching mechanism like targetService (like
HTTP path segments) also make sense.

Peter





-----Original Message-----
From: Eric Johnson [mailto:eric@tibco.com] 
Sent: Tuesday, October 07, 2008 4:37 PM
To: Peter Easton
Cc: public-soap-jms@w3.org
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 Wednesday, 8 October 2008 15:48:24 UTC