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: ISSUE 16 - Binding URI - alternative



First, to establish context.  My issue with the current proposal is not so
much the proposal itself (i.e. the mechanics of constructing a URI), but
the use cases which motivated the proposal.  For the purposes of this
discussion, I'll define the term deployed URI to mean the URI that a
deployed service is listening on such that a client outside the SCA Domain
can use this URI to invoke the service.  The use cases suggest that the URI
which results from the construction algorithm in the proposal are used as
'deployed URI's.  There's no where in the CD01 spec that requires this
usage of binding URIs.  The existing CD01 and this proposal talk about 'the
URI of a deployed binding'.  I'm concerned that some people interpret
'deployed URI' and 'the URI of a deployed binding' to be identical.  In my
proposal, they are not.  Further I think it is in appropriate for SCA
composites to contain deployment specific topology information such as
'deployed URI's.  The usual response to such a comment is that 'deployed
URI's are allowed in reference bindings, so we're already pregnant.  True,
but that's an accomodation for early adopters, and it's important to
remember that.  In a real production system references won't have these
brittle 'deployed URI's either, they will be found in WSDL documents or
service registries or in WSDL documents which are in service registries.

My view of these URIs is that they represent resources in the SCA Domain.
Bindings have URIs, components have URIs, services have URIs, etc.  The
URIs can be used to address deployed instances in the Domain model.  One
set of use cases involve using the URIs within management software to enact
dynamic changes on the Domain.  With this view, I think the only conflict I
have with the current proposal is over the need to have more than 1 base
Domain URI.  The essence of my alternative proposal is to assert that there
need not be more than one base Domain URI per Domain.  The current proposal
says that the base Domain URI is implementation dependent.  I agree.  If a
runtime wanted to use the URIs associated with a binding to do double duty
as a 'deployedURI' as well, I suppose we should allow that since creation
of 'deployedURI's is really up to the implementation anyway.  The other
changes you'll see are Word comments which indicate a desire to distribute
the text for constructing a component URI into the component section,
service URI construction into the service section, etc.  I would like to
add reference URIs and possibly property URIs, but I'll wait to see where
the TC lands before I put in a lot of work.


Editting the existing document is going to be painful.  I modified the
existing document very slightly, but it's going to be very hard to make
heads or tails of who changed what.  I put in some markers around points
where I added comments.  I suggest that reviewers temporarily use a
combination of accepting changes from one or more editors to make sense of
it.  There are some sections that need to be moved, but I'm quite afraid of
actually doing it.  I already had to recover the document once and have
spent more time on this than might possibly imagine.  Hopefully this is
enough to give a feel of the alternative so that we can discuss it.

(See attached file: Issue_16_URI Construction_Proposal_04.doc)

This completes my AI 2008-03-18-2

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

Issue_16_URI Construction_Proposal_04.doc



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]