Home / FAQ / Java Tools / Tools

Nik Silver

You could view Jini as "Jtrix lite". Before the desginers considered writing Jtrix they took a long look at Jini as an alternative, since in principle they aim to do the same things. They found Jini worked well for internal/trusted networks but had shortcomings for external/untrusted networks which would be most used in Web Services. Here are the key differences:

1. Isolation. Service code and client code are completely isolated. A big win here is for versioning. Suppose your Jini client used parser.jar version 1.1 and a Jini service used parser.jar version 1.2. Then, because the client and service sit in the same space, your application would fall over. With Jtrix the client and service code are completely isolated, and can use completely different versions of libraries without fear. They only need to share the same version of the (very minimal) base library and of course talk via an agreed service interface.

2. Security. A consequence of isolation. In Jini it is possible for the Jini client to sandbox itself against the Jini service code, but the Jini service has to trust the Jini client. In Jtrix no trust is assumed. The client and server cannot interfere with each other in any way.
3. Hosting service. A service that is important to Jtrix is the "hosting service". The idea is that an application can find somewhere else to run and copy itself into that space. This way an application can scale up to meet demand, distributing itself as needed. This is important for Web Services which need to respond to demand globally. With Jini a hosting service isn't practical.

4. Accountability. If you're going to allow an alien application to run on your system you must be able to monitor its resource usage (CPU, memory, disk, network connections, etc). This way you can bill the user fairly. Without this a Web Service won't be able to expand to another cluster because the cluster owner wouldn't be able to run a business viably. Jtrix has accountability built in at the base level.

These were considered key for Jtrix, and are so fundamental to any system that extending Jini would not have been possible. Much of Jtrix's core code is all about protecting one component from any other.

Since Jini and Jtrix share the same external aims they are compatible. A very sensible thing would be to have a Jtrix service export a Jini service by default. A Jtrix netlet (application component) can happily use a Jini service.