On Tue, Apr 15, 2008 at 9:35 AM, Jean-Sebastien Delfino < [EMAIL PROTECTED]> wrote:
> Comments inline. > > > Simon Laws wrote: > > > 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. > > > > (2) confuses me a little. > > The first part: "Reference targets are resolved when the first request is > made" seems like what you wanted to say under (2). > > But then the second part "the assembly model remains incomplete in terms > of runtime detail up until the point when a binding is selected, configured > and started." sounds like (1) "the assembly model is fully specified when > bindings/implementations are activated and started" > > Did I mis-understand what you meant in (2)? > > > > 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 > > > > > -- > Jean-Sebastien > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > Hmmm, that could have been clearer. Let me try 2 again. 2) Reference targets are resolved when the first request is made through the reference. The assembly model remains incomplete in terms of full runtime detail for this reference right up to the point when a message passes through a reference and a binding is selected, configured and started. I was trying to emphasize that there is a point of view that says that target resolution should be left until the latest possible moment, i.e. the point at which a message is about to be sent to the target. The implications of this, though, are more widespread that the binding implementation itself. Simon
