Still suffering from the marketing issues from way back when. Sadly, many a Jini evangelist still has vestigial aspects of the old marketing in their explanations. Time to clear the decks – here’s my Jini in a nutshell for techs:
- It’s about software services – doesn’t matter whether they run on servers, desktops, laptops, phones, toasters or anything else.
- Just because some piece of hardware uses Jini doesn’t mean that it must embed the entire Jini stack, support multicast etc.
- Jini services don’t have to be all Java.
- Services at compile time, know what other services they need to function – and it’s specified in a fashion that an IDE can reverse out for you (if I just had time to write the plugin).
- Services at compile time don’t need access to (via classpath etc) the stubs or proxies of the services they are dependent upon.
- Services can at runtime find the other services they need (without need for static naming strategies) at which point they receive the proxy or stub required to communicate with/use that service.
- The way in which services find each other is such that there’s no risk of the usual dependency loops where service y needs service x before it will start and vice versa.
- Jini Service deployment can be done in completely non-stop fashion – no restart of containers, web servers etc.
Once you’ve got your head around the above, you should probably get to grips with the Jini System Architecture which breaks down into three categories:
- Programming Model
- Infrastructure
- Services
All of which are covered in the overview section of the architecture document. Read the rest of the document and you’ll hopefully see that Jini systems aren’t like other kinds of system and require some new modes of thought.
Inspired by this from Fuzzy.
Comments Off
Entries (RSS)