Re: [sca-bindings] Re: Proposed resolution to issue 54, attempt #5

[Eric Johnson <eric@tibco.com>]

Hi Simon,

Simon Nash wrote:
> Eric Johnson wrote:
[snip]
>> I'm almost ready to throw in the towel, because I don't see that we
>> can tightly define this in a sensible way.  For services, I'd suggest
>> adding text on the order of this:
>>
>> In determining the URI for a service, implementations are encouraged
>> to attempt to honor the value(s) of @uri attribute, the URI in a
>> wsa:Address element from an endpointReference, the URI indicated by
>> WSDL port via a @wsdlElement attribute references, and the structural
>> URI for the binding.
>>
>> Comments?
>>
> I think this is too vague and we need to be more prescriptive.
>
> I don't think the <binding.sca> case is comparable.  An important
> difference is that <binding.ws> is an interoperable binding, so the
> URI used to expose a service with <binding.ws> is significant for
> interoperability with non-SCA clients.
To the contrary, though, the URI that appears in a WSDL is important for
interoperability with non-SCA clients.  My concern is that we're trying
to define a clear relationship between a URI specified in the composite
document with the one in use at runtime, and generated in a WSDL.

Fundamentally, my question is this:  What use cases do we have for
putting parameters on this relationship?  Given all the time we've spent
on this, and the continued vagueness of the problem, I don't think we
have any use cases that affect the specification.  The best use-case I
can come up with is that I may want to specify an @uri value so that at
deployment time, I have some indication of a default to use.  Yet I
think there are so many ways to solve that problem, and I don't see any
reasons for SCA to specify a particular choice.  For example, I could
imagine even defining a deployment time mapping, which maps URI X -->
{base deployment URI}+ path Y.  That, however, is an arbitrary
relationship, and there's nothing for us to specify!

We can get interoperability at the binding.ws to binding.ws level via a
fixed URI on the referencing binding.  We can get interoperability from
a non-SCA client to an SCA service by having the non-SCA client use a
generated WSDL.

So I allege that I have given up precisely zero interoperability by
side-stepping this question.
>   This consideration does not
> apply to a service with <binding.sca> which only has SCA clients
> wired to it using SCA mechanisms.  Services using <binding.sca>
> might not even have a URI, depending on what transport they use.
I agree that the binding.sca scenario is different.  However I find it
indicative that there are no normative requirements on the @uri
attribute for binding.sca.
>
> Tomorrow I will try to come up with some alternative words for
> service URIs, based on the previous proposal draft.
OK.  Thanks.

-Eric.