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

[Simon Nash <oasis@cjnash.com>]

Eric Johnson wrote:
> Mike raises a question which I don't know how to resolve:
> 
> Mike Edwards wrote:
> 
> [snip]
>>
>> 1) Lines 308 - 310 now say:
>>
>> "In some cases the URI determined by previous steps is relative to the 
>> structural URI for either an SCA service or binding.  In case of such 
>> a URI, the runtime SHOULD combine the relative URI with an absolute 
>> deployment target URI."
>>
> [snip]
>>
>> b) it introduces the concept "absolute deployment target URI" - where 
>> is this defined and described?  As a whole, it seems very vague.
>>
> I really don't know what to suggest here, in that I agree that it is 
> vague.  I had thought that Assembly had some tighter language around 
> some notion of a deployment URI, but after just reviewing, I don't see it.
> 
> I'm left with a few options, and the last one I felt like I should add, 
> just because specifying a URI for a service at the time you're composing 
> a composite is rife with issues.
> 
> Options:
> 
>     * Attempt to define what a deployment target URI would be.
>     * Vaguely state that the structural URI should be used in
>       constructing the actual deployment URI.
>     * Leave it completely to the implementation to decide what to do
>       with a URI, relative or absolute
>     * Forgo any attempt to specify how a URI is determined for a service.
> 
> My attempts at issue 54 have so far have attempted (mostly) to keep what 
> I perceived as the original intent, which allowed for specifying the URI 
> of a service as part of the design-time configuration.  However, 
> recognizing that a URI known when constructing a composite may have no 
> relationship to an actual deployed environment, it is extremely 
> difficult to say how to honor that URI.  For example, if the URI 
> indicates "http", but there's a policy intent that effectively dictates 
> HTTPS, what do we do?  Is our spec:
> 
>     * Treating this as an error?
>     * Encouraging implementations to alert users to the discrepancy?
>     * Mum on the point?
> 
> I note, in contrast to what we're currently doing with binding.ws, that 
> section 8.4 of the assembly spec, when discussing binding.sca, says "If 
> the binding @uri attribute is specified on a service, it is ignored."
> 
> 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.  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.

Tomorrow I will try to come up with some alternative words for
service URIs, based on the previous proposal draft.

   Simon

> -Eric.
> 
> --------------------------------------------------------------------- To 
> unsubscribe from this mail list, you must leave the OASIS TC that 
> generates this mail. Follow this link to all your TCs in OASIS at: 
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php