You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2008/03/06 18:50:28 UTC
Re: Domain/Contribution Repository was: Re: SCA contribution packaging schemes: was: SCA runtimes
On Fri, Feb 29, 2008 at 5:37 PM, Jean-Sebastien Delfino <
jsdelfino@apache.org> wrote:
> Comments inline.
>
> >>>>> A) Contribution workspace (containing installed contributions):
> >>>>> - Contribution model representing a contribution
> >>>>> - Reader for the contribution model
> >>>>> - Workspace model representing a collection of contributions
> >>>>> - Reader/writer for the workspace model
> >>>>> - HTTP based service for accessing the workspace
> >>>>> - Web browser client for the workspace service
> >>>>> - Command line client for the workspace service
> >>>>> - Validator for contributions in a workspace
> >
> > I started looking at step D). Having a rest from URLs :-) In the context
> of
> > this thread the node can loose it's connection to the domain and hence
> the
> > factory and the node interface slims down. So "Runtime that loads a set
> of
> > contributions and a composite" becomes;
> >
> > create a node
> > add some contributions (addContribution) and mark a composite for
> > starting(currently called addToDomainLevelComposite).
> > start the node
> > stop the node
> >
> > You could then recycle (destroy) the node and repeat if required.
> >
> > This all sound like a suggestion Sebastien made about 5 months ago ;-) I
> > have started to check in an alternative implementation of the node
> > (node2-impl). I haven't changed any interfaces yet so I don't break any
> > existing tests (and the code doesn't run yet!).
> >
> > Anyhow. I've been looking at the workspace code for parts A and B that
> has
> > recently been committed. It would seem to be fairly representative of
> the
> > motivating scenario [1]. I don't have detailed question yet but
> > interestingly it looks like contributions, composites etc are exposed as
> > HTTP resources. Sebastien, It would be useful to have a summary of you
> > thoughts on how it is intended to hang together and how these will be
> used.
>
> I've basically created three services:
>
> workspace - Provides access to a collection of links to contributions,
> their URI and location. Also provides functions to get the list of
> contribution dependencies and validate a contribution.
>
> composites - Provides access to a collection of links to the composites
> present in to the domain composite. Also provides a function returning a
> particular composite once it has been 'built' (by CompositeBuilder),
> i.e. its references, properties etc have been resolved.
>
> nodes - Provides access to a collection of links to composites
> describing the <implementation.node> components which represent SCA nodes.
>
> There's another "file upload" service that I'm using to upload
> contribution files and other files to some storage area but it's just
> temporary.
>
> I'm using <binding.atom> to expose the above collections as editable
> ATOM-Pub collections (and ATOM feeds of contributions, composites, nodes).
>
> Here's how I'm using these services as an SCA domain administrator:
>
> 1. Add one or more links to contributions to the workspace. They can be
> anywhere accessible on the network through a URL, or local on disk. The
> workspace just keeps track of the list.
>
> 2. Add one or more composites to the composites collection. They become
> part of the domain composite.
>
> 3. Add one or more composites declaring SCA nodes to the nodes
> collection. The nodes are described as SCA components of type
> <implementation.node>. A node component names the application composite
> that is assigned to run on it (see implementation-node-xml for an
> example).
>
> 4. Point my Web browser to the various ATOM collections to get:
> - lists of contributions, composites and nodes
> - list of contributions that are required by a given contribution
> - the source of a particular composite
> - the output of a composite built by CompositeBuilder
>
> Here, I'm hoping that the work you've started to "assign endpoint info
> to domain model" [2] will help CompositeBuilder produce the correct
> fully resolved composite.
>
> 5. Pick a node, point my Web browser to its composite description and
> write down:
> - $node = URL of the composite describing the node
> - $composite = URL of the application composite that's assigned to it
> - $contrib = URL the list of contribution dependencies.
>
> 6. When you have node2-impl ready :) from the command line do:
> sca-node $node $composite $contrib
> this should start the SCA node, which can get its description, composite
> and contributions from these URLs.
>
> or for (6) start the node directly from my Web browser as described in
> [1], but one step at a time... that can come later when we have the
> basic building blocks working OK :)
>
>
> >
> > I guess these HTTP resource bring a deployment dimension.
> >
> > Local - Give the node contribution URLs that point to the local file
> system
> > from where the node reads the contribution (this is how it has worked to
> > date)
> > Remote - Give it contribution URLs that point out to HTTP resource so
> the
> > node can read the contributions from where they are stored in the
> network
> >
> > Was that the intention?
>
> Yes. I don't always want to have to upload contributions to some server
> or even have to copy them around. The collection of contributions should
> be able to point to contributions directly in my IDE workspace for
> example (and it supports that today).
>
> > [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg27362.html
> [2] http://marc.info/?l=tuscany-dev&m=120422784528176
>
> --
> Jean-Sebastien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> Great summary Sebastien. Thank you.
I've been running the workspace code today with a view to integrating the
new code in assembly which calculates service endpoints i.e. point4 above.
I think we need to amend point 4 to make this work properly..
4. Point my Web browser to the various ATOM collections to get:
- lists of contributions, composites and nodes
- list of contributions that are required by a given contribution
- the source of a particular composite
- the output of a composite after the domain composite has been built by
CompositeBuilder
Looking at the code in DeployableCompositeCollectionImpl I see that on
doGet() it builds the request composite. What the last point needs to do is
- read the whole domain
- set up all of the service URIs for each of the included composites taking
into account the node to which each composite is assigned
- build the whole domain using CompositeBuilder
- extract the required composite from the domain and serialize it out.
Are you changing this code or can I put this in?
Simon
Re: Domain/Contribution Repository was: Re: SCA contribution packaging
schemes: was: SCA runtimes
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Laws wrote:
> On Fri, Mar 7, 2008 at 4:18 PM, Simon Laws <si...@googlemail.com>
> wrote:
>
>>
>> On Fri, Mar 7, 2008 at 12:23 PM, Jean-Sebastien Delfino <
>> jsdelfino@apache.org> wrote:
>>
>>> Jean-Sebastien Delfino wrote:
>>>> Simon Laws wrote:
>>>>> I've been running the workspace code today with a view to integrating
>>> the
>>>>> new code in assembly which calculates service endpoints i.e. point4
>>>>> above.
>>>>>
>>>>> I think we need to amend point 4 to make this work properly..
>>>>>
>>>>> 4. Point my Web browser to the various ATOM collections to get:
>>>>> - lists of contributions, composites and nodes
>>>>> - list of contributions that are required by a given contribution
>>>>> - the source of a particular composite
>>>>> - the output of a composite after the domain composite has been built
>>> by
>>>>> CompositeBuilder
>>>>>
>>>>> Looking at the code in DeployableCompositeCollectionImpl I see that
>>> on
>>>>> doGet() it builds the request composite. What the last point needs
>>> to
>>>>> do is
>>>>>
>>>>> - read the whole domain
>>>>> - set up all of the service URIs for each of the included composites
>>>>> taking
>>>>> into account the node to which each composite is assigned
>>>>> - build the whole domain using CompositeBuilder
>>>>> - extract the required composite from the domain and serialize it
>>> out.
>>>> Yes, exactly!
>>>>
>>>>> Are you changing this code or can I put this in?
>>>> Just go ahead, I'll update and merge if I have any other changes in
>>> the
>>>> same classes.
>>>>
>>> Simon, a quick update: I've done an initial bring-up of node2-impl. It's
>>> still a little rough but you can give it a try if you want.
>>>
>>> The steps to run the store app for example with node2 are as follows:
>>>
>>> 1) use workspace-admin to add the store and assets contributions to the
>>> domain;
>>>
>>> 2) add the store composite to the domain composite using the admin as
>>> well;
>>>
>>> 3) start the StoreLauncher2 class that I just added to the store module;
>>>
>>> 4) that will start an instance of node2 with all the node config served
>>> from the admin app.
>>>
>>> So the next step is to integrate your node allocation code with
>>> workspace-admin and that will complete the story. Then we'll be able to
>>> remove all the currently hardcoded endpoint URIs from the composites.
>>>
>>> I'll send a more detailed description and steps to run more scenarios
>>> later on Friday.
>>>
>>> --
>>> Jean-Sebastien
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>> Ok, sounds good. I've done the uri integration although there are some
>> issues we need to discuss. First I'll update with your code, commit my
>> changes and then post here about the issues.
>>
>> Regards
>>
>> Simon
>>
> I've now checked in my changes (last commit was 634762) to integrate the URI
> calculation code with the workspace. I've run the new store launcher
> following Sebastien's instructions from a previous post to this thread. I
> don't seem to have broken it too much although I'm not seeing any prices for
> the catalog items.
I was seeing that issue too before, it's a minor bug in the property
writing code, which is not writing property values correctly.
> Issues with the URI generation code....
>
> I have to turn model resolution back on by uncommenting a line in
> ContributionContentProcessor.resolve. Otherwise the JavaImplementation types
> are not read and
> compositeConfiguationBuilder.calculateBindingURIs(defaultBindings,
> composite, null); can't generate default services. I then had to tun it back
> off to make the store sample work. I need some help on this one.
I'm investigating now.
>
> If you hand craft services it seems to be OK although I have noticed,
> looking at the generated SCDL, that it seems to be assuming that all
> generated service names will be based on the implementation classname
> regardless of whether the interface is marked as @Remotable or not. Feels
> like a bug somewhere so am going to look at that next.
OK
>
> To get Java implementation resolution to work I needed to hack in the Java
> factories setup in the DeployableCompositeCollectionImpl.initialize()
> method. This is not very good and raises the bigger question about the set
> up in here. It's creating a set of extension points in parallel to those
> created by the runtime running this component. Can we either use the
> registry created by the underlying runtime or do similar generic setup.
Yes, I'd like to keep the infrastructure used by the admin decoupled
from the infrastructure of the runtime hosting the admin, but I'll try
to simplify the setup by creating an instance of runtime for the admin
and getting the necessary objects out of it, instead of assembling it
from scratch as it is now.
> The code doesn't currently distinguish between those services that are
> @Remotable and those that aren't
>
> Simon
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Domain/Contribution Repository was: Re: SCA contribution packaging
schemes: was: SCA runtimes
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jean-Sebastien Delfino wrote:
> Simon Laws wrote:
>> On Fri, Mar 7, 2008 at 4:18 PM, Simon Laws <si...@googlemail.com>
>> wrote:
>>
>>>
>>> On Fri, Mar 7, 2008 at 12:23 PM, Jean-Sebastien Delfino <
>>> jsdelfino@apache.org> wrote:
>>>
>>>> Jean-Sebastien Delfino wrote:
>>>>> Simon Laws wrote:
>>>>>> I've been running the workspace code today with a view to integrating
>>>> the
>>>>>> new code in assembly which calculates service endpoints i.e. point4
>>>>>> above.
>>>>>>
>>>>>> I think we need to amend point 4 to make this work properly..
>>>>>>
>>>>>> 4. Point my Web browser to the various ATOM collections to get:
>>>>>> - lists of contributions, composites and nodes
>>>>>> - list of contributions that are required by a given contribution
>>>>>> - the source of a particular composite
>>>>>> - the output of a composite after the domain composite has been built
>>>> by
>>>>>> CompositeBuilder
>>>>>>
>>>>>> Looking at the code in DeployableCompositeCollectionImpl I see that
>>>> on
>>>>>> doGet() it builds the request composite. What the last point needs
>>>> to
>>>>>> do is
>>>>>>
>>>>>> - read the whole domain
>>>>>> - set up all of the service URIs for each of the included composites
>>>>>> taking
>>>>>> into account the node to which each composite is assigned
>>>>>> - build the whole domain using CompositeBuilder
>>>>>> - extract the required composite from the domain and serialize it
>>>> out.
>>>>> Yes, exactly!
>>>>>
>>>>>> Are you changing this code or can I put this in?
>>>>> Just go ahead, I'll update and merge if I have any other changes in
>>>> the
>>>>> same classes.
>>>>>
>>>> Simon, a quick update: I've done an initial bring-up of node2-impl.
>>>> It's
>>>> still a little rough but you can give it a try if you want.
>>>>
>>>> The steps to run the store app for example with node2 are as follows:
>>>>
>>>> 1) use workspace-admin to add the store and assets contributions to the
>>>> domain;
>>>>
>>>> 2) add the store composite to the domain composite using the admin as
>>>> well;
>>>>
>>>> 3) start the StoreLauncher2 class that I just added to the store
>>>> module;
>>>>
>>>> 4) that will start an instance of node2 with all the node config served
>>>> from the admin app.
>>>>
>>>> So the next step is to integrate your node allocation code with
>>>> workspace-admin and that will complete the story. Then we'll be able to
>>>> remove all the currently hardcoded endpoint URIs from the composites.
>>>>
>>>> I'll send a more detailed description and steps to run more scenarios
>>>> later on Friday.
>>>>
>>>> --
>>>> Jean-Sebastien
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>
>>>> Ok, sounds good. I've done the uri integration although there are some
>>> issues we need to discuss. First I'll update with your code, commit my
>>> changes and then post here about the issues.
>>>
>>> Regards
>>>
>>> Simon
>>>
>> I've now checked in my changes (last commit was 634762) to integrate
>> the URI
>> calculation code with the workspace. I've run the new store launcher
>> following Sebastien's instructions from a previous post to this thread. I
>> don't seem to have broken it too much although I'm not seeing any
>> prices for
>> the catalog items.
>
> I was seeing that issue too before, it's a minor bug in the property
> writing code, which is not writing property values correctly.
>
>> Issues with the URI generation code....
>>
>> I have to turn model resolution back on by uncommenting a line in
>> ContributionContentProcessor.resolve. Otherwise the JavaImplementation
>> types
>> are not read and
>> compositeConfiguationBuilder.calculateBindingURIs(defaultBindings,
>> composite, null); can't generate default services. I then had to tun
>> it back
>> off to make the store sample work. I need some help on this one.
>
> I'm investigating now.
>
>>
>> If you hand craft services it seems to be OK although I have noticed,
>> looking at the generated SCDL, that it seems to be assuming that all
>> generated service names will be based on the implementation classname
>> regardless of whether the interface is marked as @Remotable or not. Feels
>> like a bug somewhere so am going to look at that next.
>
> OK
>
>>
>> To get Java implementation resolution to work I needed to hack in the
>> Java
>> factories setup in the DeployableCompositeCollectionImpl.initialize()
>> method. This is not very good and raises the bigger question about
>> the set
>> up in here. It's creating a set of extension points in parallel to those
>> created by the runtime running this component. Can we either use the
>> registry created by the underlying runtime or do similar generic setup.
>
> Yes, I'd like to keep the infrastructure used by the admin decoupled
> from the infrastructure of the runtime hosting the admin, but I'll try
> to simplify the setup by creating an instance of runtime for the admin
> and getting the necessary objects out of it, instead of assembling it
> from scratch as it is now.
>
>> The code doesn't currently distinguish between those services that are
>> @Remotable and those that aren't
>>
>> Simon
>>
>
>
Simon,
After a few more changes, the domain / node allocation, default URI
calculation and resolution of references across nodes now works OK.
I was able to remove all the hardcoded URIs in the tutorial composites
as they now get determined from the configuration of the nodes that the
composites are deployed to.
You can use the latest tutorial modules to see the end to end
integration, with the following steps:
1. Start tutorial/domain/.../LaunchTutorialAdmin.
2. Open http://localhost:9990/ui/composite in your Web browser. You
should see all the tutorial contributions and deployables that I've
added to that domain.
3. Click the feeds in the "composite install image" to see the resolved
composites.
4. Start all the launch programs in tutorial/nodes, you can start them
in any order you want.
5. Open tutorial/assets/tutorial.html in your Web browser, follow the
links to the various store implementations.
Hope this helps.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Domain/Contribution Repository was: Re: SCA contribution packaging
schemes: was: SCA runtimes
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Laws wrote:
> On Fri, Mar 7, 2008 at 4:18 PM, Simon Laws <si...@googlemail.com>
> wrote:
>
>>
>> On Fri, Mar 7, 2008 at 12:23 PM, Jean-Sebastien Delfino <
>> jsdelfino@apache.org> wrote:
>>
>>> Jean-Sebastien Delfino wrote:
>>>> Simon Laws wrote:
>>>>> I've been running the workspace code today with a view to integrating
>>> the
>>>>> new code in assembly which calculates service endpoints i.e. point4
>>>>> above.
>>>>>
>>>>> I think we need to amend point 4 to make this work properly..
>>>>>
>>>>> 4. Point my Web browser to the various ATOM collections to get:
>>>>> - lists of contributions, composites and nodes
>>>>> - list of contributions that are required by a given contribution
>>>>> - the source of a particular composite
>>>>> - the output of a composite after the domain composite has been built
>>> by
>>>>> CompositeBuilder
>>>>>
>>>>> Looking at the code in DeployableCompositeCollectionImpl I see that
>>> on
>>>>> doGet() it builds the request composite. What the last point needs
>>> to
>>>>> do is
>>>>>
>>>>> - read the whole domain
>>>>> - set up all of the service URIs for each of the included composites
>>>>> taking
>>>>> into account the node to which each composite is assigned
>>>>> - build the whole domain using CompositeBuilder
>>>>> - extract the required composite from the domain and serialize it
>>> out.
>>>> Yes, exactly!
>>>>
>>>>> Are you changing this code or can I put this in?
>>>> Just go ahead, I'll update and merge if I have any other changes in
>>> the
>>>> same classes.
>>>>
>>> Simon, a quick update: I've done an initial bring-up of node2-impl. It's
>>> still a little rough but you can give it a try if you want.
>>>
>>> The steps to run the store app for example with node2 are as follows:
>>>
>>> 1) use workspace-admin to add the store and assets contributions to the
>>> domain;
>>>
>>> 2) add the store composite to the domain composite using the admin as
>>> well;
>>>
>>> 3) start the StoreLauncher2 class that I just added to the store module;
>>>
>>> 4) that will start an instance of node2 with all the node config served
>>> from the admin app.
>>>
>>> So the next step is to integrate your node allocation code with
>>> workspace-admin and that will complete the story. Then we'll be able to
>>> remove all the currently hardcoded endpoint URIs from the composites.
>>>
>>> I'll send a more detailed description and steps to run more scenarios
>>> later on Friday.
>>>
>>> --
>>> Jean-Sebastien
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>> Ok, sounds good. I've done the uri integration although there are some
>> issues we need to discuss. First I'll update with your code, commit my
>> changes and then post here about the issues.
>>
>> Regards
>>
>> Simon
>>
> I've now checked in my changes (last commit was 634762) to integrate the URI
> calculation code with the workspace. I've run the new store launcher
> following Sebastien's instructions from a previous post to this thread. I
> don't seem to have broken it too much although I'm not seeing any prices for
> the catalog items.
I was seeing that issue too before, it's a minor bug in the property
writing code, which is not writing property values correctly.
> Issues with the URI generation code....
>
> I have to turn model resolution back on by uncommenting a line in
> ContributionContentProcessor.resolve. Otherwise the JavaImplementation types
> are not read and
> compositeConfiguationBuilder.calculateBindingURIs(defaultBindings,
> composite, null); can't generate default services. I then had to tun it back
> off to make the store sample work. I need some help on this one.
I'm investigating now.
>
> If you hand craft services it seems to be OK although I have noticed,
> looking at the generated SCDL, that it seems to be assuming that all
> generated service names will be based on the implementation classname
> regardless of whether the interface is marked as @Remotable or not. Feels
> like a bug somewhere so am going to look at that next.
OK
>
> To get Java implementation resolution to work I needed to hack in the Java
> factories setup in the DeployableCompositeCollectionImpl.initialize()
> method. This is not very good and raises the bigger question about the set
> up in here. It's creating a set of extension points in parallel to those
> created by the runtime running this component. Can we either use the
> registry created by the underlying runtime or do similar generic setup.
Yes, I'd like to keep the infrastructure used by the admin decoupled
from the infrastructure of the runtime hosting the admin, but I'll try
to simplify the setup by creating an instance of runtime for the admin
and getting the necessary objects out of it, instead of assembling it
from scratch as it is now.
> The code doesn't currently distinguish between those services that are
> @Remotable and those that aren't
>
> Simon
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Domain/Contribution Repository was: Re: SCA contribution packaging schemes: was: SCA runtimes
Posted by Simon Laws <si...@googlemail.com>.
On Fri, Mar 7, 2008 at 4:18 PM, Simon Laws <si...@googlemail.com>
wrote:
>
>
> On Fri, Mar 7, 2008 at 12:23 PM, Jean-Sebastien Delfino <
> jsdelfino@apache.org> wrote:
>
> > Jean-Sebastien Delfino wrote:
> > > Simon Laws wrote:
> > >>
> > >> I've been running the workspace code today with a view to integrating
> > the
> > >> new code in assembly which calculates service endpoints i.e. point4
> > >> above.
> > >>
> > >> I think we need to amend point 4 to make this work properly..
> > >>
> > >> 4. Point my Web browser to the various ATOM collections to get:
> > >> - lists of contributions, composites and nodes
> > >> - list of contributions that are required by a given contribution
> > >> - the source of a particular composite
> > >> - the output of a composite after the domain composite has been built
> > by
> > >> CompositeBuilder
> > >>
> > >> Looking at the code in DeployableCompositeCollectionImpl I see that
> > on
> > >> doGet() it builds the request composite. What the last point needs
> > to
> > >> do is
> > >>
> > >> - read the whole domain
> > >> - set up all of the service URIs for each of the included composites
> > >> taking
> > >> into account the node to which each composite is assigned
> > >> - build the whole domain using CompositeBuilder
> > >> - extract the required composite from the domain and serialize it
> > out.
> > >
> > > Yes, exactly!
> > >
> > >>
> > >> Are you changing this code or can I put this in?
> > >
> > > Just go ahead, I'll update and merge if I have any other changes in
> > the
> > > same classes.
> > >
> >
> > Simon, a quick update: I've done an initial bring-up of node2-impl. It's
> > still a little rough but you can give it a try if you want.
> >
> > The steps to run the store app for example with node2 are as follows:
> >
> > 1) use workspace-admin to add the store and assets contributions to the
> > domain;
> >
> > 2) add the store composite to the domain composite using the admin as
> > well;
> >
> > 3) start the StoreLauncher2 class that I just added to the store module;
> >
> > 4) that will start an instance of node2 with all the node config served
> > from the admin app.
> >
> > So the next step is to integrate your node allocation code with
> > workspace-admin and that will complete the story. Then we'll be able to
> > remove all the currently hardcoded endpoint URIs from the composites.
> >
> > I'll send a more detailed description and steps to run more scenarios
> > later on Friday.
> >
> > --
> > Jean-Sebastien
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> > Ok, sounds good. I've done the uri integration although there are some
> issues we need to discuss. First I'll update with your code, commit my
> changes and then post here about the issues.
>
> Regards
>
> Simon
>
I've now checked in my changes (last commit was 634762) to integrate the URI
calculation code with the workspace. I've run the new store launcher
following Sebastien's instructions from a previous post to this thread. I
don't seem to have broken it too much although I'm not seeing any prices for
the catalog items.
Issues with the URI generation code....
I have to turn model resolution back on by uncommenting a line in
ContributionContentProcessor.resolve. Otherwise the JavaImplementation types
are not read and
compositeConfiguationBuilder.calculateBindingURIs(defaultBindings,
composite, null); can't generate default services. I then had to tun it back
off to make the store sample work. I need some help on this one.
If you hand craft services it seems to be OK although I have noticed,
looking at the generated SCDL, that it seems to be assuming that all
generated service names will be based on the implementation classname
regardless of whether the interface is marked as @Remotable or not. Feels
like a bug somewhere so am going to look at that next.
To get Java implementation resolution to work I needed to hack in the Java
factories setup in the DeployableCompositeCollectionImpl.initialize()
method. This is not very good and raises the bigger question about the set
up in here. It's creating a set of extension points in parallel to those
created by the runtime running this component. Can we either use the
registry created by the underlying runtime or do similar generic setup.
The code doesn't currently distinguish between those services that are
@Remotable and those that aren't
Simon
Re: Domain/Contribution Repository was: Re: SCA contribution packaging schemes: was: SCA runtimes
Posted by Simon Laws <si...@googlemail.com>.
On Fri, Mar 7, 2008 at 12:23 PM, Jean-Sebastien Delfino <
jsdelfino@apache.org> wrote:
> Jean-Sebastien Delfino wrote:
> > Simon Laws wrote:
> >>
> >> I've been running the workspace code today with a view to integrating
> the
> >> new code in assembly which calculates service endpoints i.e. point4
> >> above.
> >>
> >> I think we need to amend point 4 to make this work properly..
> >>
> >> 4. Point my Web browser to the various ATOM collections to get:
> >> - lists of contributions, composites and nodes
> >> - list of contributions that are required by a given contribution
> >> - the source of a particular composite
> >> - the output of a composite after the domain composite has been built
> by
> >> CompositeBuilder
> >>
> >> Looking at the code in DeployableCompositeCollectionImpl I see that on
> >> doGet() it builds the request composite. What the last point needs to
> >> do is
> >>
> >> - read the whole domain
> >> - set up all of the service URIs for each of the included composites
> >> taking
> >> into account the node to which each composite is assigned
> >> - build the whole domain using CompositeBuilder
> >> - extract the required composite from the domain and serialize it out.
> >
> > Yes, exactly!
> >
> >>
> >> Are you changing this code or can I put this in?
> >
> > Just go ahead, I'll update and merge if I have any other changes in the
> > same classes.
> >
>
> Simon, a quick update: I've done an initial bring-up of node2-impl. It's
> still a little rough but you can give it a try if you want.
>
> The steps to run the store app for example with node2 are as follows:
>
> 1) use workspace-admin to add the store and assets contributions to the
> domain;
>
> 2) add the store composite to the domain composite using the admin as
> well;
>
> 3) start the StoreLauncher2 class that I just added to the store module;
>
> 4) that will start an instance of node2 with all the node config served
> from the admin app.
>
> So the next step is to integrate your node allocation code with
> workspace-admin and that will complete the story. Then we'll be able to
> remove all the currently hardcoded endpoint URIs from the composites.
>
> I'll send a more detailed description and steps to run more scenarios
> later on Friday.
>
> --
> Jean-Sebastien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> Ok, sounds good. I've done the uri integration although there are some
issues we need to discuss. First I'll update with your code, commit my
changes and then post here about the issues.
Regards
Simon
Re: Domain/Contribution Repository was: Re: SCA contribution packaging
schemes: was: SCA runtimes
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jean-Sebastien Delfino wrote:
> Simon Laws wrote:
>>
>> I've been running the workspace code today with a view to integrating the
>> new code in assembly which calculates service endpoints i.e. point4
>> above.
>>
>> I think we need to amend point 4 to make this work properly..
>>
>> 4. Point my Web browser to the various ATOM collections to get:
>> - lists of contributions, composites and nodes
>> - list of contributions that are required by a given contribution
>> - the source of a particular composite
>> - the output of a composite after the domain composite has been built by
>> CompositeBuilder
>>
>> Looking at the code in DeployableCompositeCollectionImpl I see that on
>> doGet() it builds the request composite. What the last point needs to
>> do is
>>
>> - read the whole domain
>> - set up all of the service URIs for each of the included composites
>> taking
>> into account the node to which each composite is assigned
>> - build the whole domain using CompositeBuilder
>> - extract the required composite from the domain and serialize it out.
>
> Yes, exactly!
>
>>
>> Are you changing this code or can I put this in?
>
> Just go ahead, I'll update and merge if I have any other changes in the
> same classes.
>
Simon, a quick update: I've done an initial bring-up of node2-impl. It's
still a little rough but you can give it a try if you want.
The steps to run the store app for example with node2 are as follows:
1) use workspace-admin to add the store and assets contributions to the
domain;
2) add the store composite to the domain composite using the admin as well;
3) start the StoreLauncher2 class that I just added to the store module;
4) that will start an instance of node2 with all the node config served
from the admin app.
So the next step is to integrate your node allocation code with
workspace-admin and that will complete the story. Then we'll be able to
remove all the currently hardcoded endpoint URIs from the composites.
I'll send a more detailed description and steps to run more scenarios
later on Friday.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Domain/Contribution Repository was: Re: SCA contribution packaging
schemes: was: SCA runtimes
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Laws wrote:
>
> I've been running the workspace code today with a view to integrating the
> new code in assembly which calculates service endpoints i.e. point4 above.
>
> I think we need to amend point 4 to make this work properly..
>
> 4. Point my Web browser to the various ATOM collections to get:
> - lists of contributions, composites and nodes
> - list of contributions that are required by a given contribution
> - the source of a particular composite
> - the output of a composite after the domain composite has been built by
> CompositeBuilder
>
> Looking at the code in DeployableCompositeCollectionImpl I see that on
> doGet() it builds the request composite. What the last point needs to do is
>
> - read the whole domain
> - set up all of the service URIs for each of the included composites taking
> into account the node to which each composite is assigned
> - build the whole domain using CompositeBuilder
> - extract the required composite from the domain and serialize it out.
Yes, exactly!
>
> Are you changing this code or can I put this in?
Just go ahead, I'll update and merge if I have any other changes in the
same classes.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org