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>
22/02/2008 15:30
|
To
|
sca-assembly@lists.oasis-open.org
|
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