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
