J5m is easy-to-use replacement for JINI in many distributed applications. It was tested as an underlying platform for a distributed crawler and it can offer production-ready stability and features. Why another middleware? The novel crawler architecture is based on a new approach, so-called ``co-operating services''. It allows us to exchange any part of the system without shutdown or restart or reload, any compatible part of the system can also process requests of another component, if such a component fails or is overhauled. Not all applications need the similar features...the point is that we did not try to develop ``another middleware'', we try to develop ``something completely different''.
You can download ready-to-go installation package from the distribution page.
We suggest you to deploy your applications as j5m JARs. It requires you to follow this simple assembly process.
J5m is still rather new in public, so its programming guide and examples are not comprehensive. Examples and important programming tricks are published in j5m-demo module. This module is part of the installation package, and you can give it a try without elaborate and time consuming experiments.
J5m simplifies a development of distributed applications. It guarantees the following operations:
J5m is still a thin layer for distributed applications. J5m is not (yet) a complex middleware with all funny bells and whistles. What are the major differencies between j5m and similar environments? The overview is presented in the following table
| j5m | RMI | JINI | |
| naming scheme | tree | tree | flat |
| local versus remote calls | both, faster is preferred automatically | remote only | remote only |
| automatic hot-spare objects | yes | no | no |
| parametric object look-up | yes | no | yes |
| life-cycle hooks | yes | no | no |
J5m allows you to quickly build and deploy distributed applications. The same could be achieved with JINI platform, but J5M offers better performance and features which are not available with JINI, e.g. hot-spare objects, direct Java calls instead of RMI, improved look-up capabilities, security, asynchronous calls, etc. Moreover, j5m is still developed actively, because it serves as an underlying platform for various web and computing related projects. An important point is that j5m is easily accessible from applications written in pure Java or Java EE or any other middleware environment you can think of.
Some features like object migration and transactions are not yet available. They will be implemented according to our development capacity and priorities. If you want to join the team, feel free to contact us!
The figure presents one of the possible deployment scenarios. Three computer nodes run the middleware platform (represented by Nuggets). Nugget and its hosted objects are assigned to a concrete domain. The domain boundaries cannot be easily crossed by distant objects. Moreover, the objects are running under a concrete application context. If you enable a platform security manager, it is also impossible to cross the application context boundaries as well.
Distant objects are accessible using a classic tree-naming schema. For instance, //domainX/base/foyer denotes a distant object running in domainX domain with local (domain's) name /base/foyer. This information is stored in the middleware registry.
The middleware registry can be implemented as an online or static service (via multicast or LDAP). Deployed applications run in both configurations without any modifications.
J5m allows you to deploy several instances of a distant object under the same name. An application code can still communicate to a concrete distant object, but if anything fails, it can quickly redirect all the communication to other (in this sense) backup or hot-spare distant objects of the same name. This redirection is managed by the middleware automatically, so that a programmer may write cleaner code and the complexity of applications is reduced significantly.