Re: [sca-assembly] ISSUE 16: Component URI is not well described

[Mike Edwards <mike_edwards@uk.ibm.com>]

Anish,

Since the (domain level) component names
are part of the URI construction and because the names of
these components must be unique, then
I think that the default URI rules mean no clashes.

Once people start playing around with
the construction rules and start using constructs like "../foo"
in 
their relative URI attributes, then
all bets are off - but if you start using such techniques, you had better
be well aware of what you are doing.

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

Anish Karmarkar <Anish.Karmarkar@oracle.com>

26/02/2008 06:57

To	David Booz <booz@us.ibm.com>
cc	sca-assembly@lists.oasis-open.org
Subject	Re: [sca-assembly] ISSUE 16: Component URI is not well described

 > 4) I really like the fact that the composites
are absent from the URI
 > construction

Wouldn't that lead to clashes?

-Anish
--

David Booz wrote:
> 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.
> 
> 2) I would like to see examples with promotion.  I found the
promotion text
> confusing.
> 
> 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.
> 
> 4) I really like the fact that the composites are absent from the
URI
> construction
> 
> 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?
> 
> 
> 
> 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
> 

---------------------------------------------------------------------
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