[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
Dave,
Can you elaborate? What URIs are independent of the deployment
topology? Clearly, the default URI construction algorithm is dependent
on the deployment topology.
Michael
-----Original Message-----
From: David Booz [mailto:booz@us.ibm.com]
Sent: Monday, February 25, 2008 10:05 PM
To: sca-assembly@lists.oasis-open.org
Subject: RE: [sca-assembly] ISSUE 16: Component URI is not well
described
Commenting only on this piece of the conversation:
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>
<MR>If the entire domain is not hosted on a single host, then at least
the
host and port of the base URI is likely to be different, according to
the
machine that is hosting each particular service. When to use https vs.
http is something that we probably won't standardize. Different ports
might be used on different machines, and in fact different services on
the
same machine might use different ports. All of these things figure into
the "authority" part of the base URI for the service URI. This is not
about whether there should be a domain URI, but is about what we can say
about the base URI used for URI construction.</MR>
My mental model has been that these URIs are independent from the
deployment topology.
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
"Michael Rowley"
<mrowley@bea.com>
To
02/25/2008 03:11 "Mike Edwards"
PM <mike_edwards@uk.ibm.com>, "OASIS
Assembly"
<sca-assembly@lists.oasis-open.org>
cc
Subject
RE: [sca-assembly] ISSUE 16:
Component URI is not well
described
Mike,
You were right that I missed the comments and questions further down in
your original email. I can see from this most recent markup, that most
of
your questions have been answered, or your guess as to the right answer
was
a good guess.
I like the current draft of this proposal, as marked up by both you and
Dave.
More comments inline below...
From: Mike Edwards [mailto:mike_edwards@uk.ibm.com]
Sent: Monday, February 25, 2008 5:10 AM
To: OASIS Assembly
Subject: 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: mike_edwards@uk.ibm.com
David Booz
<booz@us.ibm.com>
To
22/02/2008 15:30
sca-assembly@lists.oasis-open.o
rg
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>
<MR>+1. I'll also note that it may be misleading to talk about "the
base
domain URI", when there can be a different base URI used in different
circumstances around the domain. Perhaps we should just call these
implementation-dependent base URIs.</MR>
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>
<MR>The new example looks good to me.</MR>
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>
<MR>If the entire domain is not hosted on a single host, then at least
the
host and port of the base URI is likely to be different, according to
the
machine that is hosting each particular service. When to use https vs.
http is something that we probably won't standardize. Different ports
might be used on different machines, and in fact different services on
the
same machine might use different ports. All of these things figure into
the "authority" part of the base URI for the service URI. This is not
about whether there should be a domain URI, but is about what we can say
about the base URI used for URI construction.</MR>
4) I really like the fact that the composites are absent from the
URI
construction
<mje>Good</mje>
<MR>Me too</MR>>
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>
<MR>I don't feel strongly about this, but I've always thought that the
"../" construction was pretty well understood by people, so I didn't see
the need to spend a lot of time describing it. Nonetheless, it doesn't
hurt.</MR>
Michael
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
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]