[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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. 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. {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. 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. 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. 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. 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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]