On Mon, Feb 23, 2009 at 1:44 PM, Simon Laws <[email protected]>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 > <[email protected]>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
