Simon, just curious if there is any talk in SCA of having anything
similar to OSGi's
concept of service references and service trackers to permit a more
dynamic system
where services can be added to and removed from the system at runtime
without
having to restart components.
Or, is it considered to be enough for now to have the system statically
configured at
startup time?
What's the thinking on this?
--Rich
________________________________
From: Simon Laws [mailto:[EMAIL PROTECTED]
Sent: Monday, August 04, 2008 2:35 PM
To: [email protected]
Subject: Re: Question on dynamic configuration of distributed
application
On Mon, Aug 4, 2008 at 5:14 PM, Rich Smith (rjsmith2)
<[EMAIL PROTECTED]> wrote:
Thanks, Raymond. I'll investigate your suggestions, and post
back with any more
questions.
--Rich
________________________________
From: Raymond Feng [mailto:[EMAIL PROTECTED]
Sent: Monday, August 04, 2008 8:55 AM
To: [email protected]
Subject: Re: Question on dynamic configuration of distributed
application
Hi,
Thank you for your interest in Tuscany. I have two quick
comments inline.
Raymond
From: Rich Smith (rjsmith2) <mailto:[EMAIL PROTECTED]>
Sent: Monday, August 04, 2008 7:57 AM
To: [email protected]
Subject: Question on dynamic configuration of distributed
application
Resending this question now that I am able to get on the mailing
list. Apologies to
anyone who gets it twice.
Hi, all. I'm working on evaluation of Tuscany Java, and need
some advice on a
particular configuration/use-case that we are planning for our
application.
The application will be scalable from a low-end deployment where
it runs on a
single server to a high-end, distributed deployment, running on
several servers.
SCA and Tuscany seem like a good fit for this.
In the high-end case, there will be several instances of
"back-end servers", each
of which will run different instances of the same components.
The front-end will
keep a mapping of which back-end server to use for which
resources, and so this
is _not_ going to require any kind of load balancing.
So far, I've figured out that I can register the back-end server
components using
separate service names, and just get those service references
using the appropriate
names.
<rfeng>In a SCA domain, the components in top-level composites
should have unique names. But we can configure more than one components
to use the same implementation. Would it help for your use case?</rfeng>
However, I want to configure the back-ends using our application
and not using
static files (as in the calculator-distributed sample) because
it will be necessary
to allow customers to add back-end servers as they need to
increase capacity.
The thought of having to regenerate all of the .composite files
does not appeal to
me, and I don't really want to generate five copies of the same
file with different
service names.
What is the best approach for this? Is there something I can do
using SPI to
dynamically configure a distributed Tuscany Java application?
(It's probably okay
if restart is required somewhere, but it would be even better if
not.)
<rfeng>SCA does have the deployment composite concept. It allows
we use a dynamically configured composite (instead of being packaged in
a SCA contribution) to deploy the application. In Tuscany, we have the
following API:
org.apache.tuscany.sca.node.SCANode2Factory.createSCANode(String,
String, SCAContribution...)
The 2nd argument is a String representing the XML for the
deployment composite.
We also have a SCA Domain Manager in Tuscany which provides the
administration capability. It's built as a SCA composite application
with Web 2.0 front end. The function can be used programmatically to
introspect contributions/composites, resolve wirings and configure nodes
for deployment. You might be able to explore it for your purpose.
Please try the store tuturial to get a better understanding:
https://svn.apache.org/repos/asf/tuscany/java/sca/tutorials/store/domain
</rfeng>
Please let me know.
--Rich
Hi Rich
Both the calculator-distributed sample and the store tutorial, that
Raymond mentions, use the same underlying model of an SCA Domain. Here's
how it works.
- You build your application as a set of composites where each composite
may run on a separate node
- References in one composite may target services in another by explicit
name
- The workspace.xml, domain.composite and cloud.composite file you have
looked at model these composites and their association with physical
nodes
- A domain manager app uses this information to work out what the the
real URLs for services and the references that target them will be
- When you run up a node with the composite that is intended to run on
that node it is configured with the correct endpoints. Composites
running on other nodes are able to find it as they are also configured
(written on demand) by the domain manager.
As you have seen from the calculator-distributed sample this is fairly
static. There is a domain manage GUI app that allows you to add
composites to your domain which does actually write the worskpace.xml,
domain.composite and cloud.composite files for you (start the
calculator-distributed sample, ant runDomain, and point your browser at
http://l3aw203:9990/ui/home/).
You add and remove composites to configure your domain and when you are
happy with it you can start nodes out there on the network where you
expect them to be and the node will use some configuration to find the
domain manager and suck down the information relating to the composite
it is supposed to be runnning. Once you've started a node it is
currently stand alone. It won't pick up any subsequent changes you make
to the domain. To pick up changes you have to restart the node.
So how to do what you need to do?
The wrinkle you face is that in SCA component names have to be unique
(actually they only need to be unique within the context of a composite
but for the purpose of this description it's the same thing). If you
have 5 different components that you want to wire to then you need to
define 5 different components with 5 different names. They can of course
all have the sample implementation. There is no sense in the SCA
assembly model that you wire to instances of compnents. So your 5
components running on 5 different nodes are not different instances of
the same component but separate components.
In your case you are suggesting that the front end can select a service
based on some knowledge of the resource that the service is running on.
This actually sounds like it would fit the model of explicitly named
service components well as you need to differentiate a component running
on one node from a component running on a different node with different
resource properties. To add a new component though would, as you say,
require that you create a new composite for the service component. We
could get round the need to manually update the front end composite by
setting it to autowire to available component services with the right
sort of interface. You would still need to restart the front end node
though.
How does your front end app differentiate between services? If we took
the approach above the front end component would have to have a
collection of references to services (a reference with a 1..N
multiplicity) and hence no easy way to identify one reference from
another. You could of course have a method on the service that returns
information that allows you to identify the properties of the service
and relate these properties to the reference's location in the reference
collection.
There are some other tricks you could think about, for example, take a
look at demo/load-balancing -webapp. This takes a different approach and
defines a very simple two component assembly
client -> service.
The same service composite is then deployed to several different nodes.
The client thinks it's only wired to one service and always sends it's
request to the same URL, the URL in the binding of that composite.
However that URL happens to be the URL of the front end of the load
balancer that spreads the load across the separate instances of the
composite. Here you can start as many back end nodes as you like
dynamically but the front end doesn't get any control over which one is
called for any given request.
That's probably enough for now but I'm interested to hear more about
your application and how we make it run on Tuscany.
Regards
Simon
