| CONTENTS | PREV | NEXT | INDEX | J2EE BluePrints |
EJB clients are application clients that interact with the J2EE EJB tier. EJB clients are GUI programs that typically execute on a desktop computer; they manage their own GUI and offer a user experience similar to that of native applications. Here we discuss how to develop and deploy EJB clients.
EJB clients interact with the J2EE EJB tier using the RMI-IIOP protocol. A variety of middle-tier services are available to an application client:1 JNDI for directory lookups, JMS for messaging, and JDBC for relational database access.
An EJB client depends on a client container to provide some system services. Such a container is typically very lightweight compared to other J2EE containers and usually provides security and deployment services.
3.4.1.1 The Client Container
A client container is usually a library that is distributed along with the client. It is specific to the J2EE EJB container,2 and is often provided by the same vendor. The container manages details of RMI-IIOP communication. It also handles security, transaction, and deployment issues. The following discussion assumes a Java client container. The J2EE specification doesn't define service requirements for applications implemented in other languages. However, a similar set of services should be provided by containers for such clients.
3.4.1.2 Deployment
EJB application clients are packaged in JAR files that include a deployment descriptor similar to other J2EE application components. The deployment descriptor describes the enterprise beans and external resources referenced by the application. As with other J2EE application components, access to resources is configured at deployment time, names are assigned for enterprise beans and resources, and so on.
The J2EE platform does not specify tools to deploy an application client, or mechanisms to install it. Very sophisticated J2EE products might allow the application client to be deployed on a J2EE server and automatically made available to some set of (usually intranet) clients. Other J2EE products might require the J2EE application bundle containing the application client to be manually deployed and installed on each client machine. Another approach would be for the deployment tool on the J2EE server to produce an installation package that could be taken to each host to install the application client.
3.4.1.3 Transactions
Since client containers aren't required to provide direct access to transaction facilities, EJB clients should use enterprise beans to start transactions. They can also use transaction facilities of JDBC. However, doing so may be risky since the J2EE platform doesn't define a mechanism for propagating the transaction context to the EJB server.
3.4.1.4 Security
The client application must be authenticated to access the J2EE middle tier. Techniques for authentication are provided by the client container, and are not under the control of the application client. The container can integrate with the platform's authentication system, authenticate when the application is started, or use some other lazy authentication policy. The container takes responsibility for gathering authentication data from the user, by presenting a login window to the user.
EJB clients in the Java programming language execute in an environment with a security manager installed. They have similar security permission requirements as servlets.
EJB clients have a number of strengths, including:
- Provide a more flexible user interface
Application clients can be made to look and feel more like native applications on the client machine. Since these clients implement their own user interface, they can provide a richer, more natural interface to the application tasks.- Distribute the workload
An application client can share some of the computational expense by doing the task on the client desktop, and thereby reducing load on the server. In particular, the work of generating the user interface is performed by each client. This is useful for applications with specific graphical display capabilities.- Handle complex data models
Sometimes the data associated with an application is sufficiently complex and the manipulation interface rich enough, that a Web-based interface to manage the interaction is not enough. In such cases, you want direct access to the underlying object model on the client and to manipulate it directly.For example, in a financial analysis system, it might make sense to off-load some of the complex financial-projection number crunching to the client. Or consider an application that allows manipulation of CAD schemas such as a design of a circuit board (PCB). An application client, with direct access to the objects of the CAD system, can redraw views of the layout more easily than a Web-based interface, and with better performance. The server should be delegated to background tasks such as converting a PCB layout to a plot of the PCB traces.- Are transaction-capable
Since EJB clients communicate using RMI-IIOP, they are capable of participating in client-demarcated transactions through JTA APIs.- Provide integrated security
Application client containers can integrate with the security of the underlying operating system where the client is executed, thereby providing a more transparent and manageable security infrastructure.For example, in an enterprise intranet, where the client and the server belong to the same security domain, an application client container might simply forward the credentials of the user already logged into the client desktop operating system, thereby effecting single signon. A Web client, on the other hand, would require explicit sign on and security management.
The disadvantages of EJB clients are that they:
- Require explicit deployment
EJB clients need to be distributed and installed on the client desktops. In an intranet, where desktops can be standardized, this is less of an issue. However, on the Internet, distribution becomes a serious consideration. Furthermore, upgrades and fixes to the client need to be distributed as well, and the server has to deal with multiple versions of the client programs.- Require firewall reconfiguration
The RMI-IIOP protocol does not usually go through firewalls without additional setup on the firewall host. This makes use of EJB clients on the Internet very limited.- Tend to be more complex
Since the application client needs to manage its own user interface, its implementation is more complex. Furthermore, it communicates with the J2EE server at a much lower level than browser-based Web clients and needs to handle the complexity introduced as a result.
EJB clients can be implemented using either the Java programming language, or languages such as Visual Basic or C++. When a language other than Java is used, depending on the implementation on the client container, some of the facilities of the J2EE platform may not be available.
3.4.3.1 Java Technology Clients
Java clients execute in their own Java virtual machine. Following the model for Java applications, they are invoked at their main method and run until the virtual machine is terminated. Security and deployment services are provided through the use of a client container.
The Java programming language should be used for implementation of EJB clients. Since the EJB server communicates using RMI-IIOP, the client needs to support RMI-IIOP. This is most naturally done using services provided by the standard Java platform.
Some facilities cannot be easily implemented in other languages as a result, client containers for these languages may not provide the full set of features.
Java technology clients are usually stand-alone Java applications. However, when appropriately signed and trusted, Java applets can also be used as EJB clients. Applets and applications have essentially the same set of platform service available to them. Additionally, a Java applet can communicate with the Web tier as well as the application tier to get its job done. In this sense it is a multitier client.
3.4.3.2 Non-Java Clients
EJB clients can be implemented in programming languages other than Java. Since the EJB server uses RMI-IIOP, this requires some form of RMI-IIOP support available to the client.
Scripting COM objects together into an application is a common client implementation approach. It is possible for a client container to make enterprise beans appear as COM objects on the client machine.
When enterprise beans are exposed as COM objects, any scripting languages supported by the Active Scripting Engine can be used to automate the components to develop the application client. While Visual Basic is most often used for this purpose, languages such as JavaScript or Perl can also be used.
The specific approach to developing such clients will be largely dependent on the J2EE product used and the platform. Client containers will be provided by the J2EE server.
Here's an example of how such clients might work:
- Create an RMI-IIOP proxy in the client. This proxy runs in a Java virtual machine. The client uses RMI-IIOP to communicate with the EJB tier.
- The client container exposes each enterprise bean that is part of the application as a COM object by generating and a registering type library for each enterprise bean. Note that the type libraries must be installed on every client desktop. The COM objects that are registered act as enterprise bean proxies.
- When the COM
IDispatchinterface of the enterprise bean proxy object is used to make a method invocation, it communicates with the RMI-IIOP proxy using Java Native Interface, or some other proprietary mechanism. The RMI-IIOP proxy communicates with the EJB tier just like a Java application client and forwards the invocation.
Translating between one distributed computing architecture and another is not straightforward. There are some limitations when using Visual Basic clients that access the EJB tier:
- Security: It is hard to propagate security contexts between the J2EE platform and Visual Basic clients. The RMI-IIOP proxy to the EJB server appears to be the application client. The proxy thus needs to somehow authenticate the user on behalf of the Visual Basic client. Integration with the native security system is harder.
- Transactions: Transaction contexts cannot be propagated from a non-Java client to the EJB tier. Although availability of JTA or propagation of contexts is not required by the J2EE platform, it is often available in Java client containers. However, this is not possible when using the COM.
- Deployment: The type libraries that need to be generated for each enterprise bean are application-specific and need to be distributed and installed for each Visual Basic application client.
The decision to use Visual Basic clients is largely non-technical. It depends on the expertise available, as well as the desire to integrate with existing EJB clients. When legacy issues are not a concern, EJB clients should be developed using Java technology.
There is one interesting case where a COM-based scripting client might interact with an EJB server. This is the scripting present in Microsoft IIS Active Server Pages (ASP). ASPs are server-side scripting components that use Visual Basic script to produce dynamic content. An ASP developer that wishes to use the J2EE platform for its middle tier needs, can do so using the techniques outlined above.