[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sca-assembly] ISSUE 16 - Binding URI - alternative
|
I see value in David's use case for URIs – so that you can refer
to any kind of construct that has been deployed into the domain. One use
of this just came up the other day in the policy TC. We would like to be
able to create an external policy file that points to a deployed
component/service/reference/etc and associate a policy with it. It is
useful if you can refer to it with a URI. However, I see little value in customizing these URIs. I see little
reason why the structure of the domain should not translate directly into the
URI of these constructs. This customization does not seem to be
sufficiently valuable to warrant including a @uri attribute on every element of
a composite file. You also can get into some very confusing situations. If every
element can customize its URI by a @uri attribute, then you would think that a
reference binding would also be able to customize its URI, but it already has a
@uri attribute, which means something completely different. It isn’t
the URI of the binding (so you can manage it), it is the URI that the binding
will talk to. By contrast, I’ll argue that what David calls a “deployed
URI” _is_ something that
people would want to customize. This is because the URI landscape made
available to external users should be carefully constructed so that it does not
change, even when the structure of the domain changes. Java EE allows you to customize the path part of the URIs for web-apps
through the context-root
property of a deployment descriptor. In some scenarios it is also
appropriate to be able to customize the “authority” part of the URI
(e.g. http://foo.com). Customizing the authority is possible in very
simple deployments, where the host domain is fixed, or in much more complex
deployments, where you have some kind of a virtual
hosting capability. Michael -----Original Message----- 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" e-mail:booz@us.ibm.com http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]