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