Cheiron

We believe the number of serious public attempts to provide a container for Jini services is often exaggerated in the blogosphere, if you exclude the vertical frameworks for Grid computing the list is currently: Seven, Rio and Harvester.

We are not providing a full feature comparison, as we leave that up to others, but our summary for these containers is ^[1]:

• Harvester: provides a simple way to develop and deploy Jini™ applications. You build services using a servlet-like API, and the container handles some of the sticky issues in Jini - in particular it manages your codebase and provides an http server for codebase downloads. Also does it provide a limited way to find services in the djinn, most other things are currently up to the service developer.
  
• Rio: providing a model (dynamic provisioning) to dynamically instantiate, monitor & manage service components as described in an architectural meta-model. To Jini™ services (ServiceBeans) Rio also supplies various resources such as events, watches and resource pools.
  
• Seven: reference implementation of the JSC Programming Model that puts the emphasis on providing the Jini™ service developer/deployer features that are considered labor-intensive and fault-prone to implement, such as:
  • fine grained life-cycle that, amongst other things, controls the (in)ability to receive remote method invocations;
  • service registration with lookup services;
  • support for distributed events, leasing and participation in the two-phase commit protocol, these can be persisted for 'persistent' services allowing for crash recovery;
  • adding administration interfaces for join and life-cycle management;
  • simple persistence API that can be used e.g. to capture transactional state;
  • finding and tracking other services in djinn;
  • resource management (threads and leases);
  • configuration of all deployment aspects;
  • controlling codebase annotation and serving download jar files;
  • versioning of services and downloadable code;
  • installation and upgrading of services.

From the summary above you can conclude that at least Seven and Rio are created with different goals in mind. Seven provides more facilities to the developer of a Jini service, but doesn't allow you to describe a distributed system in terms of capabilities and policies (SLA, QoS) to manage these capabilities. It is therefore not correct to see these projects merely as duplicate efforts, depending on your requirements you should pick the framework that suits your needs the best. Also one must remember that Jini at heart is more about what you expose to clients and not how you implement things internally, therefore (in theory) nothing should prevent you from building a software system that is composed of services based on Seven, Rio, Harvester, JTSK starter framework, etc.

There is one interesting question and that is whether Seven, as a horizontal container, could serve as a framework for building vertical containers that are targeted for specific environments. While the JSC Specification is not the right place to explore this idea, a Seven specific API could be developed to validate this idea. We see certainly possibilities to eventually make this possible.

With regard to the question whether we should work together instead of 'divide and conquer' as there might be synergy; while in theory there might be synergy, we doubt whether in practice this would materialize given the stage the various projects are in, as well as other practical stuff such as copyright ownership, project management, etc. Also we believe it is good that various projects approach the design space with different solution to find out what is the most beneficial to the Jini Community, time will tell whether this should lead to a single API for service developers to work against.

^[1] if any of the information about the products mentioned is incorrect please let us know, only that way we can correct it.

It is likely that Seven will work with all services from the Jini Technology Starter Kit but this is not verified at a regular basis. The services in the Jini Technology Starter Kit assume the JSK Platform that differs slightly from the JSC Platform^[1], but this should not lead to problems with respect to proxies consumed by JSC Services deployed in Seven, the same the other way around.

Whether other services adhere to any platform is not clear to us at this moment. If you have information about which services work or don't work please report them to the Cheiron project as any failure is a clear indication that a 'standardized' Jini Platform should be specified.

^[1] The JSC Platform is mainly a subset of the JSK Platform with regard to downloadable code as the JSC API is only relevant for the server side and is not used by the JTSK services.