[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
From: Mike
Edwards [mailto:mike_edwards@uk.ibm.com]
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.
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.
Before adding anything to
the spec, I’ll try to answer here. Assume that each of these is for the
following deployment composite: Also assume that the
implementation dependent base URI is http://acme.com/.
<composite name="composite1"> The URI of S: http://acme.com/C1/C2/S
<composite name="composite1"> The URI of S: http://acme.com/C1/C2/T
<composite name="composite1"> The URI of S: http://acme.com/frontDoor
<composite name="composite1"> The URI of S: http://acme.com/C1/foo/S
<composite name="composite1"> The URI of S: http://acme.com/foo/S
Hope that helps. Michael
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. "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] --------------------------------------------------------------------- Unless stated
otherwise above:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]