Jini and Enterprise JavaBean Technologies: The Distributed Client Meets the Distributed Service

Print-friendly Version

Articles Index | Jini Index | Wireless Initiative

In this session, Espresso Man and Little Grasshopper explore the differing value propositions that Jini and Enterprise JavaBean (EJB) technologies offer to the developer community.

 
Q. The "differing value propositions" of EJBs and Jini? Hey Espresso Man, before I can understand how they differ, I have to understand what they are!

A. Fair enough, Little Grasshopper. To begin with, let's consider EJBs. Briefly these are Java business logic components, which can be deployed within any application server that supports the EJB Container APIs. These containers shield the EJB developer from much of the complexity (for example, multithreading, and transactions) normally faced by the writers of such logic. This increases overall developer productivity, and enhances the robustness of the resulting code.

Jini technology is focused on a different problem space. It provides for the unification of a collection of services, such as intelligent devices, into a "Jini Federation," which gives them a common device namespace, failure mode and security model (courtesy of the Jini Lookup Service (JLS)).

Such Jini Federations are both customizable for a given user and extremely fluid, as Jini devices can both add themselves when powered up, alert a network manager, and remove themselves when hardware problems occur, (for example, paper jam, out of printer toner, and so on). There is no operator intervention of any kind required.

Q. Well this certainly sounds like EJB and Jini technologies are addressing different user needs. So I think that for once you have achieved the purpose of an entire column with your answer to my first question.

A. Not so fast, impatient one! Both these technologies are so new and powerful that it is possible to believe that each can be adopted to meet nearly every application demand. Our discussion today is therefore designed to provide some examples illustrating when Jini or when EJBs are best suited for a particular use, and to determine whether any inter-technology synergy exists between them.

First consider that the Java client platform allows developers to write software that is independent of both the hardware and operating system it runs on.

EJBs extend this paradigm to the server by providing additional independence from various legacy infrastructures such as messaging middleware, transaction support, naming & directory services, object protocols and relational databases. Since these very infrastructures are used to construct a corporate enterprise, with EJBs, you write it once, it runs everywhere, and it integrates with everything.

Jini on the other hand redefines the very meaning of the client by allowing the devices it accesses to be both remote and dynamic. Essentially Jini extends the Java paradigm to make the client's device configuration independent of network topology...or with Jini, the network in effect becomes the client computer.

Q. Impressive. But is a Jini Federation then limited to collecting only devices?

A. There is nothing in the Jini architecture that imposes such a restriction. In the more general sense, a Jini Federation can be considered to collect "services" that range from intelligent physical devices (for example, disks) to software-only virtual devices (for example file systems) to Jini-compliant EJB business logic components.

In fact, the Jini client itself can be a device, as demonstrated by a configuration in which an intelligent camera uses a Jini Federation to send picture images to an intelligent printer or display... anywhere in the internet.

Q. This all seems clear enough conceptually. But didn't you mention providing some specific examples?

A. Indeed I did. But before doing that, we first have to look at these technologies in a bit more detail. From the following table, we get some useful comparitors, which deserve further expansion here.

Jini/EJB Comparison

Architectural Model

EJBs are most commonly deployed in a standard 3-tier enterprise application architecture, consisting of a client, application server and legacy server, where they execute within an EJB Container on either of the two server tiers.

As EJBs contain and execute all the business logic of the application, the EJB 3-tier architecture can be viewed as conforming to a "thin client/thick services" model, where clients are effectively supplied with a reference to a remote EJB object.

In contrast, the Jini Federation is typically used to direct communication between a client and one or more intelligent remote devices (which service the client requests). This provides Jini with a peer-to-peer "client-to- service" architecture.

The JLS returns (in response to a service name) an "access" object containing the actual logic needed to support client requests to the remote service. Therefore when the Jini client invokes a service method, the logic within this access object executes locally.

This ability to offload significant processing from the remote service onto the client, provides the Jini architect more control over the "weight distribution" between the client and server.

Underlying Protocols

EJB code can be shielded from the actual server-side object protocol deployed within the enterprise, primarily by utilizing the Java Messaging Service (JMS) API which provides a higher level event/messaging communication layer to other (possibly remote) processes(see Figure1).

Figure 1. Typical EJB Configuration Protocols

If a more direct method of communication is needed, this requires the EJB logic to explicitly access the object protocol. Typically this enterprise-level protocol is either CORBA/IIOP or DCOM (although in the latter case, after having used EJBs to ensure platform neutrality on the server nodes, it does seem a shame to throw that advantage away by placing a vendor-specific protocol on the wire).

Jini architecture on the other hand is based upon three distinct communication pathways, each with its own unique on-the-wire protocol (see Figure2).

Figure 2. Typical Jini Configuration Protocols

• Jini device services use a discovery/join protocol to announce their presence to, and register their access objects with, the Jini Lookup Service (JLS).

• The client uses RMI to communicate with the JLS, to enable it to retrieve these access objects by "type" (for example, PRINTER).

• The client then uses the access object to communicate with the Jini service. This communication is based upon a "prearranged" protocol (for example, RMI, UDP, HTTP, IIOP) between the access object and the service from which it first originated.

As a result, when accessing the service, the client sees only the interface to the access object, and remains independent of the underlying protocol used to support the communication.

Q. What about the "Best Feature" comparitor? Isn't that the key to understanding the value proposition each technology offers?

A. Good point! In fact both EJB and Jini technology each provide a very clear and distinct value proposition.

Enterprise JavaBeans

By hiding the specifics of the middleware infrastructures behind server-side Java APIs, the EJB paradigm allows EJBs to be deployed without change in any enterprise in which an EJB container can run. This subset should soon include all enterprises that are not using "homegrown" messaging and TPM middleware.

Such a "Write an EJB once, Run it in every Enterprise" capability is particularly attractive in the following two scenarios:

• A store (or hospital, bank, or hotel or...) is sold from one chain to another. The existing business logic (which for example might have depended upon BEA's Tuxedo transaction processor instead of the now required CICS product from IBM) would normally have to be discarded.

  However all business logic contained within an EJB is immediately reusable within the new chain, because it never had any dependencies on the original infrastructure.

• A large manufacturing company wishes to provide a software package to its suppliers, which will track its parts inventory by monitoring supply levels of its key components, thereby providing "just-in-time" parts delivery.

By packaging this logic as a set of EJBs, the manufacturer can ensure that it can be deployed UNCHANGED into the enterprise of all its suppliers, no matter what collection of middleware vendors they are currently using.

Jini

Let's look at Jini's value proposition as it applies to the end user, system administrator and device manufacturer rather than the corporate application developer. Remember that under the Jini architecture, the more intelligent devices become, the more interesting things they can do.

For example, consider the case of a bit-mapped printer. Traditionally after selling a unit, the manufacturer might only see followup business when the customer needed an additional printer, or simply ran out of special toner or paper.

However when the intelligence of the printer is augmented by the addition of an embedded Java JVM capable of providing programmatic support for:

• Its own unique IP address
• A device discovery/join protocol
• A micro web server such as the Java Embedded Server (JES)

then a milestone is reached in the evolution of that device! It now becomes possible for the manufacturer to access any of its sold printers via the Internet and (subject to the security considerations enforced by the individual customer) upload new objects to it. Each printer also gains the capability of directly contacting a prespecified manufacturer site.

The following additional post sale possibilities now present themselves to such a Jini-enabled printer manufacturer.

• Sell "Zero Effort" Device Diagnostic Support

  An application run by the manufacturer can download new diagnostics directly into individual printers anywhere in the Internet, either on a contractual basis, or upon printer demand when a problem occurs.

• Sell "Zero Effort" Device Enhancements

  An application run by the manufacturer can download new "Jini client" objects directly into individual printers anywhere in the Internet upon receipt of customer order. Such objects will then be automatically registered with the local Jini Lookup Service, and thus become immediately available to the user.

  One obvious example is a "POSTSCRIPT PRINTER" object that converts requests to print a postscript file into a series of bit-mapped command equivalents. Within minutes after receipt of order, the customer has access to what to all intents and purposes is a postscript printer.

  Identical techniques could be used to sell additional enhancements to the original printer hardware, such as the capability to directly printout RTF, JPG, HTML, and PDF formatted files as well.

  Jini technology thus has the potential to revolutionize the existing relationship between a device manufacturer and its customer base.

Q. Wow! That certainly exposes some differences between the advantages provided by Jini and EJB technologies. But I can still see a few points of possible confusion. First off, EJBs use a server-side API (JDBC) to communicate with legacy relational databases. Could such a relational database also be treated as a Jini device service?

A. There are several key differentiators between the normal environments of an EJB and that of a Jini device service.

• EJBs always rest securely within the enterprise, while a Jini service (particularly if it a physical device) can remain outside it. More specifically, EJB execution occurs inside a container located on an internal corporate server node, whereas the location of a Jini device service is not so restricted.

• EJBs operate as components in a 3 (or more) level tiered application architecture, while Jini services operate in a peer-to-peer architecture, because they are always directly accessible by the client.

A good rule of thumb here is that if a component is to access or support any server-side middleware, it should initially be considered an EJB. Whether such an EJB would then register itself in a nearby JLS (thereby also becoming a potential Jini service) or remain accessible only via the normal EJB location mechanism (JNDI), is then a secondary architectural decision.

So for example while a file system would normally make an excellent Jini "virtual" device service, a relational database would not, unless some careful analysis was made as to why packaging it as a "simple" EJB was insufficient.

Q. Let's turn this around. The Jini Lookup Service DOES incorporate some powerful functionality. Couldn't any of this be reused to provide necessary enterprise infrastructure capable of being accessed by an EJB?

A. In Espresso Man's humble opinion... no. The Jini Lookup Service was architected to perform more like an "Object Trading Service" than a standard Naming and Directory Service. Its additional functionality was customized for that sole purpose, rather than being generalized to provide support for a set of enterprise-level Java APIs.

As a result:

• The JLS does not support JNDI calls.
• JLS-provided Object Persistence doesn't support JDBC calls
• The JLS 3-phase Transaction Commit capability doesn't support JTS/JTA calls.
• The JLS Distributed Event facility doesn't support JMS calls.

which means none of these Jini internals are currently accessible from within the standard EJB environment, which normally relies on an EJB-enabled Application Server for this level of functionality.

Q. Hmm... these two technologies appear to be more mutually exclusive than conflicting! Where exactly are the places (if any) that they do overlap?

A. We appear to have come full circle here. As we discussed above, the two technologies are focused on two quite different problem spaces.

EJB technology is leveraging the Java platform to redefine the current model under which server-side enterprise business logic is developed and deployed.

Jini technology is leveraging the Java platform to redefine the current model under which a client discovers, manages and communicates with the services it requires.

The "overlap" between them becomes clearly visible by examining the case of a business person on the road (the user), who turns on a wireless palm pilot.

1. A hotel-based Jini Lookup Server provides access to a local printer and fax machine.

2. The user's default Jini Lookup Server provides access to a large shared "failsafe" file system at a storage outsource site that is being backed up nightly, an office-based printer and fax machine, a home computer based mailbox filled with recently arrived email, and other necessities of civilized life.

   At this point, the user's "client configuration" is constructed. Now the user can begin to access enterprise functionality.

3. The user invokes a browser to download an applet that will collect the daily expense data. The applet comes from a web server located within the user's corporate network, and a corresponding servlet is fired up to support it.

4. The applet then gathers and uploads the user's expense data into the servlet.

5. The servlet (after suitable validation) uses JNDI to locate and create the EJB that contains the business logic necessary to start a transaction that updates the corporate database with the data from the new expense report.

6. The user then saves a permanent record of the report in an "expenses" file on her failsafe file system, prints a hardcopy on the hotel's Jini enabled printer, and faxes a copy back to the Jini-enabled fax machine at her office.

So in fact, EJB and Jini technologies can be thought of as being mutually supportive rather than being mutually exclusive.

Q. You always try to end these things on an up note, don't you Mr. E?

A. Certainly Little Grasshopper. It's the hallmark of the true professional.

About the Author

Ron Kleinman is the Chief Technical Evangelist for Sun Developer Relations, and serves as Sun's representative on multiple industry-wide Java and XML standards committees. He has extensive experience consulting with developers who are trying to "java-tize" their existing applications. He has prepared and delivered numerous presentations on Java technologies both in the U.S and overseas. His particular areas of expertise include Java on the Server (EJBs and server-side APIs), Jini, Java-based device access control and management, and more recently, XML.