By dhushon on Oct 23, 2005
Jeri or “Jini Extensible Remote Invocation” has been in the back of my mind lately. My problem has been to find a way to allow for a richer interaction between a server side processing environment, and a set of client side executors. The challenge has been that traditional approaches dictate a tight coupling of a client side representation of a model and a server side implementation... with constant “polling” or firewall challenged notification.
As Sun Grid nears reality, the engineering team is focussed on enriching the experience enabling Sun Grid to be:
- a stand alone computing environment
- an integrated services platform (but still fairly discrete in functionality), or
- an extension of your data center.
The last opportunity provides the holy grail, a compute model that can dynamically flex between running services in your data center to running services in the extranet (Internet). In this case one must be concerned with the security model, the proximity to critical data/services, audit & debug, service level agreement, and so on. One model pushed by many is using the WS\* “standards” to provide the framework for interoperability, but I think that many have already learned how the programming model needs to change as the business loosely couples components and the resultant impact on compute efficiency (latency & throughput).
Java, for a long time, has been looking at models that range from JRMP, IIOP, JMS and other protocol/communications stacks, but many Java developers keep coming back to RMI because of its ability to coherently operate systems made up of local and remote objects.
Jeri has been around for a couple of years (since 2002, I believe) when a couple of critical JSR's were voted down by the JCP. At this point, the Jini team realized that there was but one way to strengthen the security model behind Jini if it weren't going to happen in the core JRE, and that was to create a new implementation of RMI on top of a novel protocol stack.
Jeri itself is a layered implementation made up of a marshaling layer, an invocation layer, and a transport layer, this allows for separation of concern and the ability to replace individual layers so long as the contracts are maintained, thereby giving systems architects a tremendous amount of flexibility around specific implementation. A really good tutorial is available here, with a few examples that really helps to make some of these key points.
Back to Sun Grid, we need to expose application interfaces that include a portal (for browser based clients) with channels provided by Sun Grid and others, a WS environment including a registry, again for Sun Grid interfaces, and 3rd party interfaces, and will probably need a more coherent set of application interfaces that bridge the POJO, Swing Framework, Jini, domain so that we can create the kinds of dynamic systems that are emerging based upon Plain Old Java Object (POJO) based components running as services.
(It should go without saying that we also need monitoring, management, debugging, metering, entitlement, ... systemic interfaces), and though they will likely be different, I think that it's well within the realm of possibility to suggest that the afore mentioned interface technologies can play a large role in realization.