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.

Main features

J5m simplifies a development of distributed applications. It guarantees the following operations:

  • Location of remote objects: all deployed objects are managed by a central LDAP server or on-line multicast messaging, thus a client object can easily find its required (server) counterpart. Any failure of LDAP server or multicast layer does not imply that the system becomes unusable.
  • Communication with remote objects: RMI is used as a primary protocol for client-server communication. The protocol may be replaced by anything else (JMS for instance), if required.
  • Optimization of remote calls: the client's connections are profiled by nuggets, so that a client will communicate with faster server objects preferably.
  • Server object loading and initialization: a programmer may define a tree of dependencies among deployed server objects, middleware will start the server objects in right order and pass them some initialization parameters.

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

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

Distributed programming with j5m at a glance

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!

j5m deployment schema

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.