This post originated from an RSS feed registered with Java Buzz
by Talip Ozturk.
Original Post: Jini vs. J2EE
Feed Title: Shared Memory
Feed URL: http://sedoparking.com/search/registrar.php?domain=®istrar=sedopark
Feed Description: about java, jini, javaspaces, programming, aop and a little bit of me and life.
I have seen people are discussing Jini vs. J2EE on various forums. while some people are not sure how to compare them, others are discussing the possiblity of creating a unified way of clustering any J2EE and Jini services. I already posted this entry for the discussion over at TSS. Here it is in case you didn't read it.
J2EE is trying to solve well-known, well-described specific problems. Things are mostly static and require more admistrative work; think about number of xml files you have to go over and server names you staticly bound. Jini on the other hand, is trying to solve network(distributed) programing problems over all by providing more dynamic, proactive behaviours. It doesn't solve any specific application-level problem though, which makes people a little uncomfortable with Jini. you hear people asking how Jini handles persistance, refering to the J2EE's Entity beans. there is no Entity bean kind of specification in Jini, and I don't think there should be. More important than that, there is no container concept in Jini, things are distributed freely as 'services'. Jini brings true 'service oriented' programing model. nodes in a Jini network would be called 'service', whereas nodes in a JXTA network would be called 'peer' and nodes in a J2EE network would be called 'j2ee server'.
They are not truely competing technologies rather complementary technologies. if you are writing a J2EE server, you can use Jini's dynamic, self healing features. if a Jini service needs to persist data in a way that entity beans does, then the Jini service can make use of a J2EE server to do that. if you are writing JMS implementation, you might want to leverage Jini JavaSpaces technology. JNDI might internally be interfacing with Jini Lookup Service to gain some dynamic behaviour.
Since Jini and J2EE has different transaction service model, it is hard to achieve true clustering among them. you might achieve load-balance and fail-over if you make some assumptions and exceptions but when it comes to replication things are more complex. in J2EE, you know what to replicate; such as statefull session beans, http session... whereas since there is no specification on custom service level specification, something like statefull/stateless jini service, you don't know what to replicate. each service has to take care of its own replication.
I think some J2EE vendors will expose a way to deploy Jini services in them. this is not much useful rather meaningless if you ask me unless J2EE server's core has strong ties to Jini. More natural cooperation of these two technologies would be that J2EE server is built on top of Jini technology and Jini services are either deployed into the J2EE servers or running remotely and making use of J2EE server for the things that J2EE is good for.
Even though marriage of Jini and J2EE is possible and might be good for some cases I still think that having Jini based infrastucture would be the best. keep J2EE as J2EE and Jini as Jini. don't try to see they are brother and sister or life-time friends.
Previous Topic
