Newsletter sign-up

View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java

Email Address:

Activatable Jini services, Part 1: Implement RMI activation

The RMI activation framework can produce self-sufficient, flexible Jini services

By Frank Sommers, JavaWorld.com, 09/15/00

A fundamental shift is taking place in the systems architectures of major software vendors. Presently, the industry aims to deliver services via software in such a way that users can interact with these services virtually anywhere, at any time, from any device. This new paradigm has been compared to a dial tone; practically anywhere in the world, one can pick up a phone and immediately hear a dial tone. Software services like banking, insurance, news, inventories, sales leads, and travel schedules may soon be as accessible as that familiar hum. IBM's WebSphere, HP's e-speak, and Microsoft's Microsoft .Net are all different manifestations of this ambitious desire, as is Sun's Jini.

TEXTBOX:

TEXTBOX_HEAD: Activatable Jini services: Read the whole series!

• Part 1: Implement RMI activation

• Part 2: Patterns of use

:END_TEXTBOX

The notion of a service lies at the heart of Jini. The Jini Specification defines a service as "... something that can be used by a person, a program, or another service ... Services will appear programmatically as objects in the Java programming language, perhaps made up of other objects ... A service will have an interface, which defines the operations that can be requested of that service. The type of the service determines the interfaces that make up that service." (See Resources for the Jini Specification.)

In Jini, a software component makes its services available through a proxy. Other services must locate that proxy to interact with a service within djinn, a federation of Jini services. Jini offers a robust mechanism, based on the Java language interfaces implemented by the proxy, that helps you look up proxies and other optional parameters. However, the ubiquitous computing environments promised by Jini and other service-oriented architectures require a service that is easily locatable and readily available.

For services with simple functionality, the proxy, once retrieved from the lookup service, might be able to operate independently -- making it a "strictly local" proxy. For instance, a service that converts decimal numbers into their hexadecimal equivalents would likely perform this computation entirely in the client's address space. For more involved services, the proxy might have to communicate with external resources running on other hosts. An example would be a currency converter, which must obtain up-to-date currency valuations to perform its service. For such a service, the proxy is not enough -- any other resources the proxy needs must also be on hand.

RMI in the Jini environment

The Jini Specification leaves the proxy, protocol, and server to communicate with the service implementation. The service implementation is hidden from the client, which only has to agree on the Java programming language interface, not a specific wire protocol, to interact with the service. Java Remote Method Invocation (RMI) can conveniently arrange such communication. All Jini services in Sun's implementation of the Jini Specification use RMI. Since Jini proxies can implement any part of the J2SE platform, of which RMI is a required component, any client VM using a Jini service proxy probably supports RMI.

 

Improve efficiency with Visual Studio(r) 2010 Beta 2. - Microsoft

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.