Next in thread →
Next in month →
RE: [sca-assembly] ISSUE 16: Component URI is not well described
Dave, Good comments - replies inline plus an updated proposal document. 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: David Booz <> 22/02/2008 15:30 To cc Subject RE: [sca-assembly] ISSUE 16: Component URI is not well described 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. <mje>OK, glad to see opinions being expressed on that point</mje> 2) I would like to see examples with promotion. I found the promotion text confusing. <mje>OK, I wondered about that myself, so I've produced some examples</mje> 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. <mje>I agree on the different Domain URIs point - what do other folk think? </mje> 4) I really like the fact that the composites are absent from the URI construction <mje>Good</mje> 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? <mje>You're right in saying that this does describe basic URI construction rules - but I defend the presence of this section in that it points out a particular usage of the rules that are relevant to particular SCA usage. I dislike specs that depend on a lot of other specs and which don't take the time to explain the more important parts of those dependencies. Such specs end up being very cryptic to the average reader. I had to go find and read the URI specs myself in order to write this section and it wasn't so easy to find and interpret the material. </mje> 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: 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 <> 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: "Michael Rowley" <> To 20/02/2008 19:45 Mike Edwards/UK/IBM@IBMGB, "OASIS Assembly" <> cc Subject RE: [sca-assembly] ISSUE 16: Component URI is not well described From: Mike Edwards [mailto:] 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: > "Michael Rowley" <> To 19/02/2008 14:36 <-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 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 Issue_16_URI Construction_Proposal_03.doc
Next in thread →
Next in month →