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 >
