Sponsored Link •
Sean Neville: One thing I think has hurt Jini a bit in the Java community is that it doesn't offer a high-level programming model per se. Jini is more a set of principles accompanied by several specific technologies, each with their own API's. You use certain utilities to handle discovery and lookup, or specific methods to use Jini transactions or events. But it has nothing quite the same as a J2EE API. It offers terrific mechanisms, but doesn't impose a specific over-arching development policy. Developers can't immediately read a book or a spec, see a specific enterprise or corporate IT ROI problem, and learn at an API level where Jini fits within their applications and architectures. In speaking with folks on the Jini team about this, I learned that the decision not to have an over-arching public API can be viewed as a strength. In focusing on a few high-level principles and building technologies that address them, Jini casts a very wide net.
Bill Venners: What do you mean by public API? Jini has one set of discovery protocols, and everything else is defined in terms of interfaces, which are APIs.
Sean Neville: Those APIs are tied to specific mechanisms rather than a programming model, whereas most J2EE APIs at least suggest a programming model. The programming model offers specific patterns for how you might arrange an application and APIs that directly support these types of patterns. By contrast, Jini APIs give you methods to perform particular types of functions.
Bill Venners: The distinction you are drawing is that Jini doesn't provide APIs that tell you how to build a Jini service. Basically, it is just up to you to build and deploy it yourself.
Sean Neville: Right. In the best-case scenario, somebody outside the Jini team would come up with those higher-level service APIs, but that hasn't happened yet, at least not in a big way, and with the possible exception of printing it also hasn't happened in a domain-specific way. However, that doesn't say anything about the technology's value. Policy is needed, but it has its negative consequences in addition to its positives. J2EE's policy is heavily oriented toward how to pump data into and out of relational databases in the most secure, scalable, managable way, without becoming domain-specific, which has a clear ROI story but also leads to debates about EJB CMP, Data Access Objects, JDO, when and where to use JDBC, and more complexities that do cost money as those debates affect specific projects over time. The absence of such a strict policy, with no over-arching architectural patterns implied by the specifications, could be a good thing for Jini. It keeps Jini open to more domain-specific work, and to new types of development beyond the database-dominated web or enterprise application. Service-oriented applications, including conversations among multiple web service peers and their rich user interfaces, might forge some policy around Jini's dynamic discovery and event mechanisms. There are also great possibilities in systems management software. As aspects of features and use cases, Jini mechanisms might be great artifacts for generative programming strategies. And of course, it can be used as an implementation mechanism for J2EE policy, which is what we did.
Bill Venners: Any complaints about your experience with Jini?
Sean Neville: My only real complaint about Jini is that it worked immediately. It was amazing how quickly we were up and running. Since it worked so quickly, I couldn't justify spending more time on it.
Bill Venners: You mean playing with it?
Sean Neville: Yes, exactly. We were spending lots of time basically reinventing Jini, and it was amazing how quickly we got the product running with Jini. It was astounding, really.
The Jini Community, the central site for signers of the Jini Sun Community Source License to interact:
Information on Macromedia JRun is at: