I'm currently bashing my head against a wall. Both physically and metaphysically.Nothing is cooler than Jini. However, unfortunately nothing is more obscure than Jini. It is something that exists etherally as a specification, not necessarily (although occasionally) as an implementation. It's the how, not the what. It's an adverb. Or something. My brain is lightly fried.
See, you can start with Jini's reference implementation via the starter kit, which exists as a concrete example of the specification. However, the last release was at the end of 2005. This is probably due to this implementation being picked up by the Apache Incubator and turned into Apache River. Apache River does seem to be under active development but has yet to issue an official release and has distributed just one release candidate.
Alright... so the Sun/Apache standard implementation is in transition. Who else has Jini services ready? Rio is a java.net project that appears to be both flexible as well as standards-compliant, so it appears to be a contender. There even appears to be moderate development traffic. However the stable binaries don't seem to match the current on-line documentation, and I haven't been able to download the latest milestone release. It does appear to have Spring integration however - and may yet be a contender. But until the documentation syncs up with the latest stable release, it's a bit hard to follow.
Cheiron also has an implementation with Seven that is Jini-compliant, and appears to be receiving some good development traffic as well. I'm still researching how to go about implementation, and their docs currently match up with their releases. I'm trying to (still) read their documentation and see what I need to do to get up to speed. It appears that most people discussing Jini in forums use Seven Suite as their implementation of choice, although Rio has a strong following as well due to its ease of Spring integration and nice administrative tools.
But for me this means I'm writing a helluva lot of "Hello World" and "Echo" applications, reading until my eyes bleed and trying to figure out how to get this all to work under a local development environment. Jini has been around forever... maybe I'm just having a hard time catching up with the rest of the world.
I'm hoping Spring Integration makes this all a bit more straight-forward for complete knobs like myself. Please oh please tell me they're adding Jini into the next milestone. Having ubiquitous services over a self-healing network is just too good. I'd love to be able to scale just by plugging in a server and walking away.
Yet another freakin' book to read - and a three-part Podcast!
ReplyDeletehttp://opencomponent.blogspot.com/2006/10/jini-new-book-and-clear-interview.html
You should check out the Newton project too (www.codecauldron.org). It uses Jini with OSGi to provide a distributed component framework in which the components can be simple POJOs (including Sprng pre-2.5) or wrappers around components based on other models.
ReplyDeleteAs you may know Spring have been moving to OSGi as their component model so this provides an ideal framework for Spring apps.
Newton is the foundation of the commercial Infiniflow Service Fabric (www.paremus.com)and the latest release just announced provides transparent support for Sprng Dynamic Modules. This functionality will be rolled in to Newton also in due course.
Mike (Paremus)
Very interesting... I'll have to try Newton out. I don't have an immediate need for transaction management or JavaSpaces, so this would work just fine. I mainly need to leverage Jini's registration and distribution (which this has) over a simple smart proxy model.
ReplyDeleteThanks! This helps!
Let me know if you still want to take a look at Rio. I've been a bit busy and have not been able to put up the release (as I have promised), put plan to shortly.
ReplyDeleteRegards
Dennis
There does appear to be a lot to like with Rio. Service dependency chains and other functionality looks great for multi-tiered transactions. Right now I'm looking at a very simple implementation, so as things expand I'll be watching Rio and Newton. Two very different frameworks of course... but then again I'm not sure which way the topography will go.
ReplyDeleteIf you look at downloading the 3.3 M1 release, check out the bean or calculator example. You'll find Its pretty straight forward to create a simple service.
ReplyDeleteHTH
Dennis
It isn't to bad to create a simple service, but it quickly ramps up when you need to look at registrar deployment, configuration management, production-level security policies, framework integration, etc.
ReplyDeleteI don't have a problem with using Jini per se... the reason I was bashing my head against a wall was because of trying to decide which implementation of the Jini spec would work best, and then determining how best to deploy it. The reason I love Jini is because so much of it automagically works, but the tough part is finally solidifying your implementation knowing you're stuck with it for another two or more years.
... when you need to look at registrar deployment, configuration management, production-level security policies, framework integration, etc.
ReplyDeleteOne of the reasons Rio helps out here is with the deployment aspects. Integrating the deployment of artifacts from configuration management is something that can be done as well. Can you shed some more light on this?
the reason I was bashing my head against a wall was because of trying to decide which implementation of the Jini spec would work best, and then determining how best to deploy it.
Hope your head feels better :) Are you talking about Jini spec versions or framework (Rio, Newton, etc ...) support?
Regards
Dennis
By "deployment" I'm actually referring to the role of operations in provisioning and deploying applications, not necessarily deploying services to be registered and recognized.
ReplyDeleteService deployment with Jini has been fine, but I mainly want to make things easier for operations to more easily roll out new versions of the registrar along with configurations. For example, it would be nice if the codebase server, registrar and configuration was deployable as a single service or WAR.
Plus any administrative consoles or registration inspection would be nice, so admins could monitor publication and distribution.