You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Kapish Aggarwal <sc...@gmail.com> on 2007/04/23 16:58:26 UTC
Setting up a Tuscany runtime to run multiple applications
I am interested in setting up a single instance of the Tuscany runtime
to run multiple SCA applications. I noticed that the SimpleRuntime and
SimpleRuntimeInfo classes define a 1:1 relationship between the
runtime and an SCA application. Based on this mechanism, I believe I
can do the following to create a runtime class that can handle
multiple SCA applications:
1) Extend RuntimeInfo to create a information object to reflect the
environment of 1:n runtime:applications.
2) Extend the AbstractRuntime class to create a runtime instance with
the methods and code to start and stop individual applications from a
single runtime.
3) Define a class to manage the Runtime and allow an interface for
starting and stopping applications (much in the manner that
DefaultSCARuntime manages SimpleRuntimeImpl).
Obviously this is a high-level look at how I would implement it. Is
this a good way to go about setting a 1:n environment or is there some
other mechanism I overlooked?
Kapish Aggarwal
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Setting up a Tuscany runtime to run multiple applications
Posted by Raymond Feng <en...@gmail.com>.
Yes, you're right.
Thanks,
Raymond
----- Original Message -----
From: "Greg Dritschler" <gr...@gmail.com>
To: <tu...@ws.apache.org>
Sent: Monday, April 30, 2007 9:06 AM
Subject: Re: Setting up a Tuscany runtime to run multiple applications
> On 4/24/07, Greg Dritschler <gr...@gmail.com> wrote:
>>
>> I'm also wondering about the code in DeployerImpl.deploy that connects
>> objects. It starts as follows:
>> // Connect components, services and references
>> List<SCAObject> scaObjects = componentManager.getSCAObjects ();
>
>
> Is it fair to say that the ComponentManager's interfaces to keep a list of
> model objects and corresponding SCAObjects is a workaround for the
> Deployer
> to find the objects created by the Builder, and that when we have a better
> integration between the runtime and the assembly models that these
> interfaces are likely to disappear?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Setting up a Tuscany runtime to run multiple applications
Posted by Greg Dritschler <gr...@gmail.com>.
On 4/24/07, Greg Dritschler <gr...@gmail.com> wrote:
>
> I'm also wondering about the code in DeployerImpl.deploy that connects
> objects. It starts as follows:
> // Connect components, services and references
> List<SCAObject> scaObjects = componentManager.getSCAObjects ();
Is it fair to say that the ComponentManager's interfaces to keep a list of
model objects and corresponding SCAObjects is a workaround for the Deployer
to find the objects created by the Builder, and that when we have a better
integration between the runtime and the assembly models that these
interfaces are likely to disappear?
Re: Setting up a Tuscany runtime to run multiple applications
Posted by Greg Dritschler <gr...@gmail.com>.
I've determined that there are a lot of dependencies on having a single
ComponentManager. DeployerImpl, BuilderRegistryImpl, and
DatabindingModuleActivator assume there is one. I'm now thinking it would
be simplest to have a single ComponentManager and make it a little smarter
about how it organizes its list of SCAObjects.
On 4/25/07, Greg Dritschler <gr...@gmail.com> wrote:
>
> I'm still having difficulty with the cardinality of the
> ContributionService and related services (ComponentManager, Deployer) and
> have to think about it some more.
>
>
Re: Setting up a Tuscany runtime to run multiple applications
Posted by Greg Dritschler <gr...@gmail.com>.
On 4/25/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>I'm not sure that there's a 1..1 relationship between application and
contribution.
No, there isn't. In trying to switch terminology from application to
contribution, I mistakenly implied an equivalence which isn't true. But you
caught the gist of my question anyway. Thanks.
I'm still having difficulty with the cardinality of the ContributionService
and related services (ComponentManager, Deployer) and have to think about it
some more.
Re: Setting up a Tuscany runtime to run multiple applications
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Some comments inline.
Greg Dritschler wrote:
> On 4/24/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>> You'll need one instance of ArtifactResolver per application as well.
>
> Is the ArtifactResolver eventually intended to resolve artifacts within a
> single contribution ("application") only or across contributions in the
> domain? The comments at the top of the interface make me think it is the
> latter.
I'm not sure that there's a 1..1 relationship between application and
contribution. For one thing, a contribution can reference artifacts
outside itself, potentially in other contributions, so an application
will probably need a graph of contributions instead of just one
contribution. Another scenario is when a given contribution declares
multiple (deployable) composites containing multiple top level
components. I would have to understand the deployment scheme you have in
mind, but if you want to have one application per top level component
for example, then you'll have multiple applications using the same
contribution (and its dependencies).
To try to answer your specific question on ArtifactResolver. I think
that an ArtifactResolver should handle a graph of contributions: a
contribution, the other contributions it depends on, and imported
external resources as well. If you're mapping this graph to what you
mean by "application" then you need one ArtifactResolver per application.
If you're referring to the following comment at the top ArtifactResolver:
"In the SCA assemblies, these various artifacts are referenced using
either QNames or URIs that do not point to a specific entity. Resolution
of these references to concrete artifacts is necessary as part of the
operation of the SCA domain."
... this is simply trying to say that artifact resolution is an
important function in an SCA domain.
Here's an extract from the SCA assembly spec covering the same subject:
"The SCA artifact resolution is likely to be most useful for SCA domains
containing heterogeneous mixtures of contribution, where
artifact-related or packaging-related mechanisms are unlikely to work
across different kinds of contribution."
> If instead it is the case that it resolves artifacts within a
> single contribution only, it isn't clear to me how to set this up since
> there seems to be a 1:1 relationship between the ContributionService
> and the
> ArtifactResolver.
>
Here is how the relationships are set up at the moment:
- one ArtifactResolver per ContributionService
- multiple ContributionServices per contribution repository (this may
change as we've just started to implement this repository thing)
- multiple Contributions per ContributionService
- multiple Contributions per contribution repository
So I would recommend to create one instance of ContributionService per
application, with its own ArtifactResolver. This will give you the
ability to have isolated applications, one or more contributions per
application, potentially sharing artifacts (and their resolution)
between the contributions loaded in that application.
To make this more concrete, I'll probably spend a little bit of time and
will try to come up with a slightly different variation of
SimpleRuntimeImpl showing how to do that, but that will basically just
split the start method into two methods around line 148.
> I'm also wondering about the code in DeployerImpl.deploy that connects
> objects. It starts as follows:
> // Connect components, services and references
> List<SCAObject> scaObjects = componentManager.getSCAObjects();
>
> Since there is one deployer, and the deployer has one component manager,
> this says to me that every time a composite is deployed, all
> registered SCA
> objects are going to be connected. If multiple contributions are
> deployed
> is that what should happen?
>
I don't think that the deployer should attempt to rewire components that
have already been wired :) I'm not sure I fully understand your question
as deployment/wiring is not really related to contributions and wiring
needs to go across components in different contributions, but let me
investigate this code further and see if there is a problem in the
Deployer, or not, when multiple applications are activated separately.
> Greg Dritschler
>
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: Setting up a Tuscany runtime to run multiple applications
Posted by Greg Dritschler <gr...@gmail.com>.
On 4/24/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> You'll need one instance of ArtifactResolver per application as well.
Is the ArtifactResolver eventually intended to resolve artifacts within a
single contribution ("application") only or across contributions in the
domain? The comments at the top of the interface make me think it is the
latter. If instead it is the case that it resolves artifacts within a
single contribution only, it isn't clear to me how to set this up since
there seems to be a 1:1 relationship between the ContributionService and the
ArtifactResolver.
I'm also wondering about the code in DeployerImpl.deploy that connects
objects. It starts as follows:
// Connect components, services and references
List<SCAObject> scaObjects = componentManager.getSCAObjects();
Since there is one deployer, and the deployer has one component manager,
this says to me that every time a composite is deployed, all registered SCA
objects are going to be connected. If multiple contributions are deployed
is that what should happen?
Greg Dritschler
Re: Setting up a Tuscany runtime to run multiple applications
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Kapish Aggarwal wrote:
> I am interested in setting up a single instance of the Tuscany runtime
> to run multiple SCA applications. I noticed that the SimpleRuntime and
> SimpleRuntimeInfo classes define a 1:1 relationship between the
> runtime and an SCA application. Based on this mechanism, I believe I
> can do the following to create a runtime class that can handle
> multiple SCA applications:
>
> 1) Extend RuntimeInfo to create a information object to reflect the
> environment of 1:n runtime:applications.
>
> 2) Extend the AbstractRuntime class to create a runtime instance with
> the methods and code to start and stop individual applications from a
> single runtime.
>
> 3) Define a class to manage the Runtime and allow an interface for
> starting and stopping applications (much in the manner that
> DefaultSCARuntime manages SimpleRuntimeImpl).
>
> Obviously this is a high-level look at how I would implement it. Is
> this a good way to go about setting a 1:n environment or is there some
> other mechanism I overlooked?
>
> Kapish Aggarwal
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Hi,
What you're describing looks OK to me. SimpleRuntimeImpl is not meant to
be used as-is in a multi-application server environment, but you can
extend AbstractRuntime to create a similar runtime class that will
integrate multiple-applications. If you look at the code in
SimpleRuntimeImpl.start(), I think that everything up to the creation of
the Scope registry can be done once for all applications, the rest of
this code can be done on an application basis. The ContributionService
will allow you to load isolated SCA contributions for each application.
You'll need one instance of ArtifactResolver per application as well.
ComponentManager will allow you to register your applications under
different URIs (unless you want to use multiple component managers).
Finally Component has start/stop methods to allow you to start/stop
components when an application starts/stops.
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