Managed SCA Environment

[Phil Housley <un...@gmail.com>]

Hi list,

I've been thinking about how I would like to be able to use Tuscany
and SCA in a large deployment, and have been trying to work out a plan
for this.  Basically my idea is to try and implement a sort of
lightweight managed environment, using a few of the principles of
current application servers, but generally trying to keep things down
to a minimum, to ensure that everything is still independently
usable/testable/etc, and avoid the pitfalls of EJB environments.

My idea for a perfect environment is one where deploying a single SCA
contribution is as simple as starting some sort of server, and asking
it to host a composite and expose the services, just like you can do
now, but then seemlessly expand the system to include more machines,
virtual and physical as required, or add extra monitoring and failover
systems, and so on.

The core of the system would be a primary server, with a similar
function to, for example, weblogic's administration server.  You would
start this and import your contribution, and then be asked whether you
would like to run it.  This is basically a souped up version of the
domain manager module that exists in 1.x.  The next step in building a
distributed system would be to start a secondary server on the target
host, and connect this to the admin server, by giving addresses and
optionally keys.  You would then be able to target specific composites
to the secondary server, and the admin server would distribute
contributions and tell it to start.

At this stage it would necessary to define some sort of communication
protocol, preferably implemented using SCA of course, so that the
servers could keep in contact.  This is a bit awkward as it would
might look initially like some sort of proprietary extension to the
SCA standard, but something could probably be organised.  With this
all in place it would then be possible for the admin server to monitor
and control all secondary servers.  At any time that services were
down on these, the admin server could decide whether it was
appropriate to rehome the composite, either internally or at another
secondary server, and contact all servers with rewritten composites if
they need to access the moved service.

The admin server could also acquire any sort of extra management
functions as required.  The basic options would allow things like
starting and stopping services, controlling access, and so on.  A next
level could be replacing failed services, as described above.  Another
layer above that would be monitoring loads, and balancing requests
between hosts offering the same services.  As all services in the
domain would be on managed servers, it would be possible to
dynamically alter a secondary server to acquire a service from a
different location than it was original told - when a server was
overloaded another instance of the composite could be started
elsewhere, and half the users of that service provided with new
composites telling them of the new location.  Beyond that, I haven't
thought far, but it seems like there would be plenty of possibilities
- automatic updating of contritbutions would be a good one.

Importantly though, there would be no requirement for the admin server
to be always running.  At any time that the secondary servers are
functioning normally, they would be completely standalone, so the
system wouldn't be dependendent on any individual host.

This is basically then the spec for a project I'd like to work on.  I
should stress that I am really not in a position to make this thing
now, I just don't know Tuscany or SCA well enough, but I do intend to
work towards it, and would be very happy to hear from anyone who is
interested, or even who can suggest a different solution.  I have
considered how I would like to work with SCA, but that really does not
mean that I'm permanently wedded to a system like the one described
here.

So, any input will be warmly welcomed!

Ok, thanks everyone for your time.

-- 
Phil Housley

Re: Managed SCA Environment

[Simon Laws <si...@googlemail.com>]

On Mon, Feb 23, 2009 at 1:44 PM, Simon Laws <si...@googlemail.com>wrote:

> Hi Phil
>
> Great post! You may already know this but a bit of background on where we
> are now. When we first started looking at domain management we were using
> SCA to support interaction between the domain and the nodes and there was a
> level of dynamic behavior. However it started to get complicated so we
> pulled back and we went for the static approach you see in the code base at
> the moment. With the static approach you add all your contributions to the
> domain, configure which nodes will run what and then fire up your nodes
> giving them the URL of the domain with the node name tacked on the end. Each
> node then contacts the domain and pulls down their specific configuration
> using an Atom feed.
>
> We have had some conversations about making this more dynamic, for example,
> allowing contributions to be added after the first node has started. However
> we need to be a little careful as adding a contribution potentially has an
> effect on all of the nodes that are already running. We need to look
> carefully at what scenarios we are trying to support. Raymond put together a
> handy page of the basic scenario we support in the domain now (
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Composite+Application+Deployment+with+SCA+Domain
> ).
>
> We haven't discussed management much and it's something we should do more
> on.
>
> Some more comments in line...
>
> Simon
>
> On Mon, Feb 23, 2009 at 1:05 PM, Phil Housley <un...@gmail.com>wrote:
>
>> Hi list,
>>
>> I've been thinking about how I would like to be able to use Tuscany
>> and SCA in a large deployment, and have been trying to work out a plan
>> for this.  Basically my idea is to try and implement a sort of
>> lightweight managed environment, using a few of the principles of
>> current application servers, but generally trying to keep things down
>> to a minimum, to ensure that everything is still independently
>> usable/testable/etc, and avoid the pitfalls of EJB environments.
>>
>> My idea for a perfect environment is one where deploying a single SCA
>> contribution is as simple as starting some sort of server, and asking
>> it to host a composite and expose the services, just like you can do
>> now, but then seemlessly expand the system to include more machines,
>> virtual and physical as required, or add extra monitoring and failover
>> systems, and so on.
>
>
> To dimensions to the expansion I think you are suggesting here.
>
> - expand the set of nodes to increase throughput, provide failover etc
> - expand the application with more contributions (which of course need new
> nodes to run them)
>
>
>>
>>
>> The core of the system would be a primary server, with a similar
>> function to, for example, weblogic's administration server.  You would
>> start this and import your contribution, and then be asked whether you
>> would like to run it.  This is basically a souped up version of the
>> domain manager module that exists in 1.x.  The next step in building a
>> distributed system would be to start a secondary server on the target
>> host, and connect this to the admin server, by giving addresses and
>> optionally keys.  You would then be able to target specific composites
>> to the secondary server, and the admin server would distribute
>> contributions and tell it to start.
>
>
> This is kind of what happens now with the atom feed that the domain
> exposes. Something else that springs to mind that might improve usability
> would be the ability to start a node with a set of contributions and have
> the node register these with the domain to avoid the user having to do
> manual configuration. Just an option, i.e. wouldn't replace the ability of a
> user to configure a domain manually.
>
>
>>
>>
>> At this stage it would necessary to define some sort of communication
>> protocol, preferably implemented using SCA of course, so that the
>> servers could keep in contact.  This is a bit awkward as it would
>> might look initially like some sort of proprietary extension to the
>> SCA standard, but something could probably be organised.
>
>
> At the moment we have the domain manager exposing atom feeds using an SCA
> Atom binding but the nodes reading them use Java HTTP calls. It would
> certainly be worth discussing looking at how far this can take us. It works
> well in this case where we have the nodes looking after themslelves. I could
> even work if we wanted to make configuration updates avaialble. However the
> nodes would have to poll.
>
>
>> With this
>> all in place it would then be possible for the admin server to monitor
>> and control all secondary servers.  At any time that services were
>> down on these, the admin server could decide whether it was
>> appropriate to rehome the composite, either internally or at another
>> secondary server, and contact all servers with rewritten composites if
>> they need to access the moved service.
>
>
> Sounds like an interesting bit of research. As you are suggesting this
> feels like another level of complexity over the based domain support.
>
>
>>
>>
>> The admin server could also acquire any sort of extra management
>> functions as required.  The basic options would allow things like
>> starting and stopping services, controlling access, and so on.  A next
>> level could be replacing failed services, as described above.  Another
>> layer above that would be monitoring loads, and balancing requests
>> between hosts offering the same services.  As all services in the
>> domain would be on managed servers, it would be possible to
>> dynamically alter a secondary server to acquire a service from a
>> different location than it was original told - when a server was
>> overloaded another instance of the composite could be started
>> elsewhere, and half the users of that service provided with new
>> composites telling them of the new location.  Beyond that, I haven't
>> thought far, but it seems like there would be plenty of possibilities
>> - automatic updating of contritbutions would be a good one.
>
>
> There are quite a few pieces of instrastructure that do this grid/cloud
> type of management. It would be worth us looking around at what works out
> there and see if a distributed Tuscany runtime can exploit something that
> already works.
>
>
>>
>>
>> Importantly though, there would be no requirement for the admin server
>> to be always running.  At any time that the secondary servers are
>> functioning normally, they would be completely standalone, so the
>> system wouldn't be dependendent on any individual host.
>
>
> +1
>
>
>>
>> This is basically then the spec for a project I'd like to work on.  I
>> should stress that I am really not in a position to make this thing
>> now, I just don't know Tuscany or SCA well enough, but I do intend to
>> work towards it, and would be very happy to hear from anyone who is
>> interested, or even who can suggest a different solution.  I have
>> considered how I would like to work with SCA, but that really does not
>> mean that I'm permanently wedded to a system like the one described
>> here.
>
>
> Sounds good Phil. I look forward to seeing how this develops.
>
>
>>
>>
>> So, any input will be warmly welcomed!
>>
>> Ok, thanks everyone for your time.
>>
>> --
>> Phil Housley
>>
>
>
Hi Phil

I should also have pointed out that another thread started recently up about
distributed OSGi and dynamic wiring [1]. This thought may also help us shape
how the domain support evolves and how to make it relevant to a wider set of
people.

Regards

Simon

[1] http://osdir.com/ml/dev-tuscany.apache.org/2009-02/msg00419.html

Re: Managed SCA Environment

[Simon Laws <si...@googlemail.com>]

Hi Phil

Great post! You may already know this but a bit of background on where we
are now. When we first started looking at domain management we were using
SCA to support interaction between the domain and the nodes and there was a
level of dynamic behavior. However it started to get complicated so we
pulled back and we went for the static approach you see in the code base at
the moment. With the static approach you add all your contributions to the
domain, configure which nodes will run what and then fire up your nodes
giving them the URL of the domain with the node name tacked on the end. Each
node then contacts the domain and pulls down their specific configuration
using an Atom feed.

We have had some conversations about making this more dynamic, for example,
allowing contributions to be added after the first node has started. However
we need to be a little careful as adding a contribution potentially has an
effect on all of the nodes that are already running. We need to look
carefully at what scenarios we are trying to support. Raymond put together a
handy page of the basic scenario we support in the domain now (
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Composite+Application+Deployment+with+SCA+Domain
).

We haven't discussed management much and it's something we should do more
on.

Some more comments in line...

Simon

On Mon, Feb 23, 2009 at 1:05 PM, Phil Housley <un...@gmail.com>wrote:

> Hi list,
>
> I've been thinking about how I would like to be able to use Tuscany
> and SCA in a large deployment, and have been trying to work out a plan
> for this.  Basically my idea is to try and implement a sort of
> lightweight managed environment, using a few of the principles of
> current application servers, but generally trying to keep things down
> to a minimum, to ensure that everything is still independently
> usable/testable/etc, and avoid the pitfalls of EJB environments.
>
> My idea for a perfect environment is one where deploying a single SCA
> contribution is as simple as starting some sort of server, and asking
> it to host a composite and expose the services, just like you can do
> now, but then seemlessly expand the system to include more machines,
> virtual and physical as required, or add extra monitoring and failover
> systems, and so on.


To dimensions to the expansion I think you are suggesting here.

- expand the set of nodes to increase throughput, provide failover etc
- expand the application with more contributions (which of course need new
nodes to run them)


>
>
> The core of the system would be a primary server, with a similar
> function to, for example, weblogic's administration server.  You would
> start this and import your contribution, and then be asked whether you
> would like to run it.  This is basically a souped up version of the
> domain manager module that exists in 1.x.  The next step in building a
> distributed system would be to start a secondary server on the target
> host, and connect this to the admin server, by giving addresses and
> optionally keys.  You would then be able to target specific composites
> to the secondary server, and the admin server would distribute
> contributions and tell it to start.


This is kind of what happens now with the atom feed that the domain exposes.
Something else that springs to mind that might improve usability would be
the ability to start a node with a set of contributions and have the node
register these with the domain to avoid the user having to do manual
configuration. Just an option, i.e. wouldn't replace the ability of a user
to configure a domain manually.


>
>
> At this stage it would necessary to define some sort of communication
> protocol, preferably implemented using SCA of course, so that the
> servers could keep in contact.  This is a bit awkward as it would
> might look initially like some sort of proprietary extension to the
> SCA standard, but something could probably be organised.


At the moment we have the domain manager exposing atom feeds using an SCA
Atom binding but the nodes reading them use Java HTTP calls. It would
certainly be worth discussing looking at how far this can take us. It works
well in this case where we have the nodes looking after themslelves. I could
even work if we wanted to make configuration updates avaialble. However the
nodes would have to poll.


> With this
> all in place it would then be possible for the admin server to monitor
> and control all secondary servers.  At any time that services were
> down on these, the admin server could decide whether it was
> appropriate to rehome the composite, either internally or at another
> secondary server, and contact all servers with rewritten composites if
> they need to access the moved service.


Sounds like an interesting bit of research. As you are suggesting this feels
like another level of complexity over the based domain support.


>
>
> The admin server could also acquire any sort of extra management
> functions as required.  The basic options would allow things like
> starting and stopping services, controlling access, and so on.  A next
> level could be replacing failed services, as described above.  Another
> layer above that would be monitoring loads, and balancing requests
> between hosts offering the same services.  As all services in the
> domain would be on managed servers, it would be possible to
> dynamically alter a secondary server to acquire a service from a
> different location than it was original told - when a server was
> overloaded another instance of the composite could be started
> elsewhere, and half the users of that service provided with new
> composites telling them of the new location.  Beyond that, I haven't
> thought far, but it seems like there would be plenty of possibilities
> - automatic updating of contritbutions would be a good one.


There are quite a few pieces of instrastructure that do this grid/cloud type
of management. It would be worth us looking around at what works out there
and see if a distributed Tuscany runtime can exploit something that already
works.


>
>
> Importantly though, there would be no requirement for the admin server
> to be always running.  At any time that the secondary servers are
> functioning normally, they would be completely standalone, so the
> system wouldn't be dependendent on any individual host.


+1


>
> This is basically then the spec for a project I'd like to work on.  I
> should stress that I am really not in a position to make this thing
> now, I just don't know Tuscany or SCA well enough, but I do intend to
> work towards it, and would be very happy to hear from anyone who is
> interested, or even who can suggest a different solution.  I have
> considered how I would like to work with SCA, but that really does not
> mean that I'm permanently wedded to a system like the one described
> here.


Sounds good Phil. I look forward to seeing how this develops.


>
>
> So, any input will be warmly welcomed!
>
> Ok, thanks everyone for your time.
>
> --
> Phil Housley
>