On Sun, Feb 3, 2008 at 5:36 AM, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> Lou Amodeo wrote: > > > This is a request to propogate the value of a references target= > > attribute > > as a first class attribute on its associated bindings model object. > > This request is based on a requirement to provide support to implement a > > late-endpoint resolution capability for service references when a > > reference > > specifies the target= attribute. This value in conjunction with a domain > > wide services registry allows the binding invokers to use the value > > specified for <reference target="" as a key to perform a service lookup > > to > > obtain the services endpoint URI dynamically during the invocation of > > the > > service rather than during compositie startup. The primary benefits of > > this > > approach are to provide a degree of location transparency for services > > and > > remove the requirement of the client from knowing the services endpoint > > at > > installation time. This would only apply to clients that are running in > > the > > same domain as the services they reference. > > > > > After reading the whole thread I'm confused and would like to walk through > a simple scenario with two composites A and B, A containing component > references to components in B. > > Here are the steps I'm thinking about for A and B: > > A1. contribution A is installed in the domain. > A2. deployable composite A is selected for deployment. > A3. policy sets are configured and applied to elements of A. > A4. A's references and dependencies are validated and satisfied. > A5. composite A is deployed to SCA machine 1. > A6. components in composite A are started. > A7. a reference wired to a component in B is invoked. > > B1. contribution B is installed in the domain. > B2. deployable composite B is selected for deployment. > B3. policy sets are configured and applied to elements of A. > B4. B's references and dependencies are validated and satisfied. > B5. composite B is deployed to SCA machine 2. > B6. components in composite B are started. > B7. a reference wired to a component in B is invoked. > > By SCA machine I mean a logical processor responsible for instantiating > components and executing their implementations (a server, a process, a node, > a webapp, or whatever applies to your particular architecture). > > Would it be possible to describe the timing of the A steps function of the > B steps, for example > A1 < B1 > A2 < B1 > A3 < B1 > A4 > B5? > etc? > > That will help me understand your requirement and what you're expecting of > the various configuration and resolution steps. > > Thanks! > -- > Jean-Sebastien > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > Hi This conversation proved inconclusive but has been dormant for a while so I'm raising it again as there have been several emails recently that touch on peoples different perceptions of how Tuscany could/should operate , e.g. [1], . Maybe we shouldn't be debating the merits of early vs late binding of reference targets in isolation but use this as very specific example of a more general question. How much flexibility of distributed operation does Tuscany allow for people implementing extensions. Going back to Lou's reference target question that started the referenced thread. IIUC the two views stated are. 1 - Reference targets are resolved before composites are deployed and run and in this way the assembly model is fully specified when bindings/implementations are activated and started 2 - Reference targets are resolved when the first request is made and in this way the assembly model remains incomplete in terms of runtime detail up until the point when a binding is selected, configured and started. Tuscany has taken both of these approaches and is now tending toward 1. It would be useful to have some confirmation Lou's view with comments on Sebastien's previously stated scenario. Generally there are a number of points of interest (to me at least). A - Access to model information. Bindings are not configured with information about their intended target and I guess there could be other information that bindings require for late resolution. B - Open building phases that give extensions the opportunity to override Tuscany logic, for example, binding matching and selection. C - Recognition of the flexibility of extension operation, for example, in this late resolution case [1] points out that functions like getService() should cater for the case that a proxy may be requested for a reference that is not yet resolved. So should Tuscany mandate the mechanism for distributed operation or should extension developer have the flexibility to influence it. Thoughts? Simon [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg30309.htm
