Well, my grasp of Jini is limited at best, so don't consider this definitive. But the basic difference in intent between HiveMind and Jini is that HiveMind deals in the local while Jini deals in the remote. HiveMind's core has no concept of remoteness, though an adjunct library knows how to find EJBs. Presumably another adjunct would be able to hook Jini services into HiveMind. But the focus of HiveMind is on constructing a universe of services available to a single JVM by building up your classpath.
Luke ---- Original message ---- >Date: Fri, 9 Apr 2004 06:28:01 -0400 >From: Ronald Simmons <[EMAIL PROTECTED]> >Subject: Hivemind and Jini >To: [email protected] > >Ok, so I'm new here, forgive me if this sounds like a troll. It is not >intended to be one. > >I've read the documentation and am still left wondering what the >intended design differences are between Hivemind and Jini. The >important ones I have been able to discern so far are: > >1 - No hot loading of code in Hivemind >2 - No defined tuplespace engine in Hivemind >3 - Non-XML config files in Jini >4 - No multi-cast discovery mechanisms for the registry in Hivemind >5 - No (or poor) integration with J2EE in Jini >6 - Apache licensing (Hivemind) vs SCSL licensing (Jini) > >I guess a place where the documentation leaves me a bit confused as >well is with regards to remote invocation of services. Is it the case >that I could write an RMI or WS interceptor for a Hivemind service and >vend that in a Jini LUS or a WS Registry? If I'm right there, then I >think I see how I'd use Jini, J2EE and Hivemind together. Otherwise, >I'm extremely confused. > >Thoughts? > >rvs > > > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
