river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <ge...@cox.net>
Subject What will eventually be in River?
Date Mon, 01 Dec 2008 19:06:59 GMT
The recent question about containers and the numerous responses indicate that 
there are many different people and projects who have been interested in a 
container mechanism for Jini service deployment and management.  I'd like to 
start a list of container features discussion.

What I am interested in, is seeing if there are a set of foundational 
capabilities which all of these different container systems have/provide and if 
there is a way that perhaps the totality of all such features might be 
integrated into a "container" for River in the not too distant future.

I really feel that deployment control and management of the system overall is an 
important part of how Jini will succeed overall.

Would the authors of the various containers be interested in providing a list of 
features that they feel their containers provide?

I'll start the process by providing a list of things that I think containers are 
known to provide at a high level.  Lower level details such as how those things 
are provided might be interesting to discuss as well.

What I consider to be the core functionality of a container is the following set 
of capabilities.

1.	Remote deployment control.  Can you attach to a VM and start a new
	service/instance remotely?
2.	Remote configuration management.  Can you ship a new configuration and
	restart a service with that configuration remotely?
3.	Versioning in deployment mechanisms to allow old services to be unloaded
	and upgraded instances started without a restart of the VM.

The following are things which might help with use in a particular environment. 
  These are things which I have heard others mention here that are either 
interesting or required attributes for their needs.

4.	Support for integration into a J2EE server (I understand that apache has
	the needed support for security manager and class loader selection to
	make this possible, while others perhaps still don't?).
5.	Spring based deployment/configuration.  I.e. is spring used as a primary
	mechanism in your containers APIs/implementation.

I'm interested in responses to the completeness of this list of things that 
might be the "core" of a good Jini container.  There are of course a whole slew 
of things that are what I consider implementation details that could be required 
attributes.  These are things like how APIs for container use impact existing 
software modules, interface vs abstract class issues etc.  I'm not as interested 
in low level details for this discussion, but I'd like to hear what people think 
is valuable to them.

Gregg Wonderly

Mime
View raw message