[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-bindings] Re: Proposed resolution to issue 54, attempt #5
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]