Hi Gregg I work with users, not developers, of a Jini container. I thought I'd put in a word for what's important to us in terms of Jini service containers. We looked at several when moving to Jini a couple of years ago, and as I've noted before, settled on Bantam, but I think our criteria apply regardless of our current choice.
One thing that distinguishes Bantam from other approaches is that Bantam offers a framework for hosting services, rather than a program which launches and starts services. That is, we can deploy a Bantam-based service within any standard Java web container (I believe you could use other containers to initiate the process, though). Thus Bantam allows us to package up our services and deploy them, along with some Bantam libraries, in a container-ized format, if one can put it that way. Specific questions about Bantam (or Mayflower, which provides for Jini configuration via Spring) can go to Tom Cellucci, the project owner. I apologize in advance if I misrepresent Bantam in any way. - We favor using a "standard" container, such as a JEE or servlet container, over a custom one specific to Jini, as there is usually more documentation, testing, support for the standard containers as such. That's not a hard-and-fast rule, but it's an advantage for us if we can deploy services in, say, a WAR file in an unmodified servlet container such as Tomcat. It's easier to convince our administrators to accept a "standard" container in the production systems than (yet another) custom one. - We found it advantageous if the container could serve as a codebase for its own services. There may be reasons not to do this, but having the codebase problem--packaging and deploying JAR files--solved for us by the Jini service framework was a real boon. Bantam can package dependent/downloadable classes automatically on startup, and associate the codebase URL as necessary during export. Generally this means that if the web container goes down, so does the codebase server, which seems about right in the simple case. - Deploy and undeploy of services is, for us, determined by the number of services in the WAR. We use standard WAR deploy/undeploy tools available with the web container. - The granularity, so to speak, of services in a deployment unit (WAR) is up to us. We can have many service interfaces, or just one, in any deployment unit. - Remote deployment can be done with standard WAR deployment tools. - Remote admin, in our case, is currently handled via JMX. Using the support for JMX annotations in recent versions of Spring, plus centralized JMX consoles, makes this very comfortable. We haven't found a need for service administration above and beyond what we can currently achieve via JMX. - We don't have a policy for versioning (live updates to services), though are planning on it. Unclear that we need any special support for this from the Jini container, however, and weren't planning on having any; rather, we'd rely on version information in the service attributes and our custom service-lookup code on the client. - Support for Spring-based configuration, replacing the custom Jini config files, has been important to us, mainly because many of our other (non-Jini) servers were already relying heavily on Spring, and we can leverage this know-how across the team. We still use the Jini configuration file format for our LUS and associated codebase, but not for our own services. - Support for auto-discovery of services by the Jini container, at startup, has proven useful. Within the service classes, we use Java annotations to declare the service name and some attributes of the service. Additional configuration which is better off externalized is handled via Spring. The Jini container locates services in the WAR automatically at startup, prepares downloadable Jars, exports services, etc. all based on these annotations and the associated Spring config. For the service developer, this brings the conceptual effort of designing a service closer to the conceptual cost of designing the interface. Generally speaking, on our team we have a sort of infrastructure budget. While we spend quite a bit on infrastructure, it doesn't pay our bills, so we have to choose carefully where to deploy those resources. Being able to deploy into a standard container using standard tools (e.g. 'any' servlet container with its tools) reduces our investment in custom infrastructure. Being able to easily declare new services for export, for example by breaking up large Java interfaces, or merging smaller ones, is important to us. Also, while we expect that the developers who end up writing Jini services should know the basics of Jini, we also need them to be problem domain experts, and anything the infrastructure can offer to reduce the conceptual load of creating, modifying, and extending services is a plus. Thus, the closer we can get to "just use these annotations, make sure this is serializable, configure these two or three beans, etc.", the more those developers can focus on what the service needs to do, rather than how its launched, hosted, or made available over the network. Of course we have cases where someone has to dig deeper into the guts of Jini, but we try to avoid this unless necessary. To be honest, Bantam does have some gotchas, in particular related to how JARs, classes and resources are located within the WAR file. Tom can clarify the exact reasons, but it's not (in its current state) without some learning curve. Personally, I would be glad to see the various projects in this area (service container, configuration) work on a common solution, possibly a "low-end" solution for simple cases, and an upgrade path to "high-end", more complex solutions. In particular, it's worthwhile to note how much both the Spring libraries (and there are many), along with annotations, have made some rather dreary tasks like working with JMX and AOP very simple. JPA is another good example of, for the most common case, simplifying what used to be a mess of configuration. I think we in the Jini community can learn from this and apply it to the Jini landscape. I also feel that given the low activity in many Jini-related open source projects, it would be worth our while to pool several projects together into a smaller number of more active projects. I hope this is helpful in some way, and I'm glad that you launched the discussion. Regards Patrick
