tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Laws" <simonsl...@googlemail.com>
Subject Re: Using contributions in the tutorial, was: Improving the store tutorial module structure
Date Thu, 03 Jan 2008 21:23:55 GMT
Hi Sebastien

This is interesting, a few more questions below to see if I can get to what
you are thinking.

Simon

On Jan 3, 2008 7:36 PM, Jean-Sebastien Delfino <jsdelfino@apache.org> wrote:

> Simon Laws wrote:
> > On Jan 3, 2008 5:59 PM, Jean-Sebastien Delfino <jsdelfino@apache.org>
> wrote:
> >
> >> [snip]
> >> Rajini Sivaram wrote:
> >>> Shouldn't resolution be associated with a contribution rather than a
> >>> composite contained within it?
> >> Resolution is performed against a set of installed contributions. It
> >> should be performed when it is assumed that all required contributions
> >> are available.
> >>
> >> When a composite is assigned to a node,
> >>> should the node find out which contribution it came from
> >> Yes
> >>
> >> and process all
> >>> composites and componentType files from the contribution?
> >>>
> >> - load in the node the contributions in the contribution dependency
> tree;
> >> - process only implementations and composites referenced by the
> >> composite deployed on the node.
> >>
> >> --
> >> Jean-Sebastien
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >> And believe it or not this is pretty much what the domain tries to do.
> I'm
> > still left with the problem of how to deal with contributions that are
> added
> > to the domain in arbitrary orders. I just assume users add them in the
> > correct order at the moment and return the errors that happen if they
> don't.
>
> It's a reasonable limitation, for now.
>
> > Maybe this is where we need an "installed contribution" concept.
>
> The contribution service should just not trigger any resolution when the
> contribution is added.

I think that's OK. By  "installed contribution" I mean a structured record
of what is available to each node as assigned by the domain. Currently the
deployed composite is held alongside a list of the contributions that, by
implication, are required by the composite. This may be OK as is but the
generation of this information could be delayed until a composite is
assigned to a node by starting it (startComposite is beginning to feel like
the wrong word for that method).

To determine which contributions are required to support a composite a few
things are required.

- which contribution holds the composite
- which contributions the resulting contribution depends on
 and so on.

To do this based on the information from the read and resolved contributions
the contributions have to be read and resolved in reverse order given the
current contribution processor API.

At the moment the domain interface doesn't directly relate the request to
start a composite with the contribution in which to find that composite (its
worked out as the contributions have been processed by that stage). We could
make it so. Is that what you were thinking?

If so are you also including changes to the domain service in your mental
model so that contributions can be read in some arbitrary order and then
resolved once they have all been read?


>
> >
> > From there I can walk the tree and present the contributions that are
> > required by a deployed composite to the node in the correct order. Not
> well
> > tested yet though.
>
> there will be no need to figure out the order (as it may not be possible
> to figure the order anyway) if the resolution is deferred to after the
> contributions are installed.

What does installed mean here? Do you mean what we have talked about above,
i.e. the selection of a composite to run on a node and the identification of
all of the contributions that are required to support it?

Also when you say " no need to figure out the order" is this because you
have contribution service changes in mind so that read and resolve for a
single contribution are not tightly coupled.

>
>
> >
> > Simon
> >
>
>
> --
> Jean-Sebastien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message