[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-assembly] ISSUE 16: Component URI is not well described
> 4) I really like the fact that the composites are absent from the URI > construction Wouldn't that lead to clashes? -Anish -- David Booz wrote: > Unfortunately I'm being called away on other business next week, so I'll > drop my comments here for the record. > > 1) implementation dependent Domain URI - YES, it should be implementation > dependent, but don't feel strongly. I'll note that one must create a > Domain before one can install or deploy anything into it, so installing the > first contribution with the definitions file containing the Domain URI > definition in it will be awkward at best. I would prefer that it was up to > the runtime to create Domains and manage them however they want. I'd like > it to be possible for SCA runtime to create relationships between the > Domain and other scoping mechanisms, so the more room we have in the spec, > the better. > > 2) I would like to see examples with promotion. I found the promotion text > confusing. > > 3) I have no idea why we'd want to support different Domain URIs for two > services that are in the same domain. What's the point of having a domain > URI then? I note that it is currently possible for a binding to provide an > absolute URI, so perhaps this is the thought behind multiple Domain URIs. > I would be fine with the removal of absolyute URIs for bindings. > > 4) I really like the fact that the composites are absent from the URI > construction > > 5) I'm not sure that 9.2.1.1 is really needed. It's just basic URI > resolution rules. For example, ./foo is also a valid relative URI that I > think ends up having no effect on any parent URI segments. I suspect > there's more of these kinds of things, do we really want to describe them > all? > > > > Dave Booz > STSM, SCA and WebSphere Architecture > Co-Chair OASIS SCA-Policy TC > "Distributed objects first, then world hunger" > Poughkeepsie, NY (845)-435-6093 or 8-295-6093 > e-mail:booz@us.ibm.com > http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome > > > > Mike Edwards > <mike_edwards@uk. > ibm.com> To > "OASIS Assembly" > 02/21/2008 06:35 <sca-assembly@lists.oasis-open.org> > AM cc > > Subject > RE: [sca-assembly] ISSUE 16: > Component URI is not well described > > > > > > > > > > > > Michael, > > I don't know if you noticed the set of comments that I inserted into your > original proposal text - I note that you did > not make any response to those comments. > > I've taken your original document, your examples below and I've built a > revised version of the proposal, which > also contains the changes to the Component section of the specification. > All based on the latest WD-03 version > of the Assembly specification: > > > > This contains various tweaks, which are fully change marked. > > Yours, Mike. > > Strategist - Emerging Technologies, SCA & SDO. > Co Chair OASIS SCA Assembly TC. > IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain. > Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431 > Email: mike_edwards@uk.ibm.com > > > "Michael Rowley" > <mrowley@bea.com> > > To > 20/02/2008 19:45 Mike Edwards/UK/IBM@IBMGB, "OASIS > Assembly" > <sca-assembly@lists.oasis-open.org> > cc > > Subject > RE: [sca-assembly] ISSUE 16: Component > URI is not well described > > > > > > > > > > > > > > > > > From: Mike Edwards [mailto:mike_edwards@uk.ibm.com] > Sent: Wednesday, February 20, 2008 6:46 AM. > To: OASIS Assembly > Subject: Re: [sca-assembly] ISSUE 16: Component URI is not well described > > > Michael, > > Thanks for getting this done. > > First, some high level observations. > > - this is clearly a proposal that involves more than simply improving the > description of how URIs are constructed. There are some > significant changes and additions to the capabilities here - all I'm asking > for is that everyone should be clear about this. I'm not > against the changes, but would like us to be clear about them. > > - I note that you are making it explicit that the Base Domain URI is set in > some implementation dependent way. Is this something that > everyone is happy with? Do we instead need a way of capturing this > information, say in a definitions file? > > I believe that even before the SCA 1.0 spec was published there was a > general agreement among the authors that this should be left unspecified, > but that fact never made it into the spec. There may be many factors into > deciding what host and port to use, whether to use https vs. http, etc. We > then should just say how URIs are constructed below that. > > > - I find the notation concerning cardinality that is being used somewhat > confusing. While I think I follow that "Component URI" may turn > up one or more times, I'm not clear which portion of the complete URI is > targeted by the "?" notation at the end - is it just the Binding URI > or does it also apply to the Service Name? ie which of these is intended: > > > Implementation-Dependent Base URI / {Component URI /}+ Service Name {/ > Binding URI}? > > > Implementation-Dependent Base URI / {Component URI /}+ {Service Name / > Binding URI}? > > > You are right that I meant the first of these, and I agree that your > suggested syntax makes it clearer. > > > > I assume it's the first of these, but the text below does not make this > clear (it would be useful to explicitly state the cardinality in the text > as well). This implies that I'm answering your question about an empty > Binding URI in the negative - ie the complete URI should NOT > end with a "/". > > - I am keen on examples - I'd like to see examples for various cases not > covered at the moment: > > > Before adding anything to the spec, I’ll try to answer here. Assume that > each of these is for the following deployment composite: > > <composite name="forDeployment"> > <component name=”C1”> > <implementation.composite name=”ns:composite1”/> > </component> > </composite> > > > Also assume that the implementation dependent base URI is http://acme.com/. > > > > a) a service exposed by a nested component (no component URIs) > > > <composite name="composite1"> > <component name=”C2”> > <implementation.foo/> > <service name=”S”/> > </component> > </composite> > > > The URI of S: http://acme.com/C1/C2/S > > > > b) a service with a relative binding URI > > > <composite name="composite1"> > <component name=”C2”> > <implementation.foo/> > <service name=”S”> > <binding.ws uri=”../T”/> > </service> > </component> > </composite> > > > The URI of S: http://acme.com/C1/C2/T > > > > c) a service with an absolute binding URI > > > <composite name="composite1"> > <component name=”C2”> > <implementation.foo/> > <service name=”S”> > <binding.ws uri=”http://acme.com/frontDoor”/> > </service> > </component> > </composite> > > > The URI of S: http://acme.com/frontDoor > > > > d) a service exposed by a component with a component URI attribute > specified > > > <composite name="composite1"> > <component name=”C2” uri=”foo”> > <implementation.foo/> > <service name=”S”/> > </component> > </composite> > > > The URI of S: http://acme.com/C1/foo/S > > > > e) a service exposed with a shortened URI > > > <composite name="composite1"> > <component name=”C2” uri=”../foo”> > <implementation.foo/> > <service name=”S”/> > </component> > </composite> > > > The URI of S: http://acme.com/foo/S > > > > For these examples, appropriate composites should be shown, with relevant > attributes on elements > such as bindings, services, components - and the resulting URI quoted. > > > Hope that helps. > > > Michael > > > > > I'm happy to help create these examples. > > > Yours, Mike. > > Strategist - Emerging Technologies, SCA & SDO. > Co Chair OASIS SCA Assembly TC. > IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain. > Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431 > Email: mike_edwards@uk.ibm.com> > > > > "Michael Rowley" > <mrowley@bea.com> > > To > 19/02/2008 14:36 <sca-assembly@lists.oasis-open > .org> > cc > > Subject > [sca-assembly] ISSUE 16: > Component URI is not well > described > > > > > > > > > > > > > > > > > > > > > > I’ve enclosed a proposed modification to section 9.2 to improve the > description how URIs should be constructed. The enclosed Word document has > change tracking to show how it has changed. I’ve also included it into the > email, so that people can comment on or question specific sections as part > of this email thread. > > > > > > Note that this URI construction requires that there be a new optional @uri > attribute on components. The ability to specify a URI (which is usually > relative) makes it possible to design the URI hierarchy independent from > the structure of the domain, which I believe is valuable. > > > <mje> This will require changes to the text fo the section dealing with > components - and this should be included in the eventual proposal text. > </mje> > > > > > > Michael > > > > > > 9.2 Form of the URI of a Deployed Binding > > > > > > 9.2.1 Constructing Hierarchical URIs > > > Bindings that use hierarchical URI schemes construct the effective URI with > a combination of the following pieces (using a pseudo-BNF representation of > its structure): > > > Implementation-Dependent Base URI / {Component URI /}+ Service Name / > Binding URI? > > > > > > Each of these components deserves addition definition: > > > Implementation-Dependent Base Domain URI . SCA does not specify the > content of the base URI that should be used for any deployed binding, > except to say that it must be a hierarchical URI. There is also no > requirement that the base URI be the same for any two uses of it. > > > <mje> That final sentence is cryptic in the extreme. I'd appreciate a good > explanation of what you mean by it </mje> > > > {Component URI /}+. This is a “/” separated sequence of the relative URIs > specified by components (or the component name, if a URI is unspecified). > These are the relative URIs of the components, starting from the > domain-level component and following down each of the > <implementation.composite> components until reaching a component that > exposes the service that the binding is for. This means that promoted > services get a URI which is computed based on the highest promotion of that > service, not based on the lowest-level component that offered the service > to be promoted. > > > Service Name. The service name is the name of the service that the binding > is for, as defined by the component’s component type. > <mje> A component does not have a component type. An implementation has a > component type. So at best this should read: > > > "as defined by the component type of the component's implementation". > > > </mje> > > > Binding URI. The Binding URI is the relative URI specified in the “uri” > attribute of a binding element of the service. The default value of the > attribute is value of the binding’s name attribute treated as a relative > URI. If the binding has neither a @uri nor a @name attribute, then the > last path segment of the URI will not be present (i.e. it defaults to the > empty string). > > > The binding URI may also be absolute, in which case the absolute URI fully > specifies the full URI of the service. Some deployment environments may > not support the use of absolute URIs in service bindings. > > > <mje> OK, here we have (yet) another optional conformance point. Do we a) > want to allow this optionality b) prefer to outlaw the use of absolute > URIs for simplicity </mje> > > > The name of the containing composite does not contribute to the URI of any > service, but the name of the higher-level component that uses the > containing composite as an implementation is used instead. > > > <mje> I suggest removing the word "instead" at the end of this > sentence</mje> > > > For example, a service where the Base URI is "http://acme.com", the > component is named "stocksComponent" and the service name is "getQuote", > the URI would look like this: > > > http://acme.com/stocksComponent/getQuote > > > Allowing a binding’s relative URI to be specified that differs from the > name of the service allows the URI hierarchy of services to be designed > independently of the organization of the domain. > > > It is good practice to design the URI hierarchy to be independent of the > domain organization, but there may be times when domains are initially > created using the default URI hierarchy. When this is the case, the > organization of the domain can be changed, while maintaining the form of > the URI hierarchy, by giving appropriate values to the uri attribute of > select bindings. Here is an example of a change that can be made to the > organization while maintaining the existing URIs: > > > To move a subset of the services out of one component (say "foo") to a new > component (say “bar”), the new component should have bindings for the moved > services specify a URI “../foo/MovedService”.. > > > The URI attribute may also be used in order to create shorter URIs for some > endpoints, where the component name may not be present in the URI at all. > For example, if a binding has a uri attribute of "../myService" the > component name will not be present in the URI. > > > <mje> I know that this material about binding URIs is not new, but the > special meaning of "../" deserves some fuller explanation - and it also > raises the question of whether this can be used in the component URIs</mje> > > > 9.2.2 Non-hierarchical URIs > > > Bindings that use non-hierarchical URI schemes (such as jms: or mailto:) > may optionally make use of the “uri” attritibute, which is the complete > representation of the URI for that service binding. Where the binding > does not use the "uri" attribute, the binding must offer a different > mechanism for specifying the service address. > > > <mje>An example of a non-hierarchical URI is called for, I think</mje>:) > > > > > > > > > [attachment "URI Construction.doc" deleted by Mike Edwards/UK/IBM] > > > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in > OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > > > > > > > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > > > > [attachment "Issue_16_URI Construction_Proposal_02.doc" deleted by David > Booz/Poughkeepsie/IBM] > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and 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]