OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[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 ---Proposal for Aliases

This works for the use cases I had in mind.

Though you didn't mention it, I think we wouldn't need the uri attribute on
component any longer (it could be removed from the current proposal) nor
would we need it for services or bindings on services (this will raise some
eyebrows).  Bindings on references would still need something in order to
address services at hardcoded address.

Dave Booz
STSM, BPM and SCA Architecture
Co-Chair OASIS SCA-Policy TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093  or  8-295-6093

             Mike Edwards                                                  
             ibm.com>                                                   To 
                                       "OASIS Assembly"                    
             07/01/2008 10:16          <sca-assembly@lists.oasis-open.org> 
             AM                                                         cc 
                                       [sca-assembly] ISSUE 16: Component  
                                       URI is not well described ---       
                                       Proposal for Aliases                


At the F2F meeting, when Issue 16 was discussed, it became clear that there
was a requirement for there to be what
I described as "Aliases" for the structural URIs for a component.

A short reminder of the context for this discussion.

The latest proposal for Issue 16 treats the Component URI as effectively a
structural URI - the URI describes the place
of a given component in the Domain, starting at the Domain level component
and, where a component is implemented
by a composite, tracing downwards from the domain level through each
"nested composite", adding in the name of
the component at each level.  Where a given composite is used as an
implementation multiple times by different
components, the components within that composite end up with multiple of
these URIs, one for each "usage instance".

So far so good.

These structural URIs can be used for a number of purposes.  Concentrating
on their use for administration and management
purposes, it is required that a given component instance can be given a URI
which does not change even if the structure of
the artifacts in the domain does get changed.

I term this "unchanging" URI a "URI Alias" - effectively it is a "fixed"
URI that maps to a specific structural URI - a kind of Map.

Where should these "URI Aliases" be declared and what data should they

In my opinion, these URI Aliases should be declared at the Domain level -
in a Definitions file, for example.  It is hard to make
Aliases work well if the data is inside the composites that might be
reused, since it is hard to make them aware of the multiple
uses of a composite as an implementation.

So a simple idea is to create an <alias/> element which would live inside a
<definitions/> element (logically at the Domain level)

<alias aliasURI="xs:string" actualUri="xs:string"/>

- this is a simple mapping from the (unchanging) aliasURI to the actual
structural URI of some component - if the component moves)
due to some deployment activity, the aliasURI remains unchanged and stable,
but the actualURI needs updating to point to the new
location of the component.

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

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
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]