Local and remote interfaces for flexible EJB use (i)

Introduction

With the advent of the EJB 2.0 specification, Enterprise Java beans can have a local interface, a remote interface, or two interfaces at the same time, providing a great degree of flexibility for EE developers and architects. Implementing two interfaces gives the bean client and the bean itself the freedom to develop scenarios. Depending on the relative position of the client and the EJB, you can set the best way to access the Bean's logic. The local interface provides optimized access to the EJB if the client and the Bean are in the same Java Virtual machine (Java MACHINE,JVM), and the remote interface can be used in the distributed architecture. Combining these two types of interfaces in a single application to support two ways to access the Bean helps reduce design constraints.

It makes sense to weigh the pros and cons of design decisions by making certain things specific, such things as test results, case studies, preferably methods and tools rather than just requests and responses. This article attempts to provide more information about the local and remote interfaces that use EJBS (based on the sample Java application). By using the development and testing environment of the WebSphere Studio application Developer, we will implement a topology of two Java EE application architectures, run applications, and with the help of simple Java HTTP The client tests the application to obtain performance-related responses and data for consideration.

Architecture selection for Java EE applications

In general, the simplest topology is that every component of the Java EE application is in the same WebSphere application Server, the same JVM, the same node, or the machine. In such cases, the WebSphere application Server provides the Servlet container and the EJB container (Figure 1). This full-text topology (we'll omit firewalls, load balancers, converters, and so on) is called the "All-in-one" topology.

Figure 1. Simple Java EE application topology: All-in-one

This is the default topology for WebSphere Test Environment (WTE) in WebSphere Studio application Developer Version 5.1 (hereinafter referred to as Application Developer). However, such topologies can be successfully used as part of the site architecture for production environments. With the advent of the EJB 2.0 specification, you can communicate with EJBS in the same EJB container using the local interface in any Java component of the EE application.

Sometimes, you need to detach the Servlet and EJB containers, for example, for application security considerations. The application architect or developer can choose to place the Servlet container on different nodes, thus making the Java EE application topology more complex (as shown in Figure 2), which we call the "detach container (separate containers)" topology. In fact, WebSphere application server can be used as an efficient Servlet container and EJB container, but to make things easier to differentiate, we include the Tomcat application server and the Servlet container.

Figure 2. Topology: Separating containers (separate containers)

In the detach container (separate containers) topology, the only way the Web part of the Java-EE application communicates with the EJB is through a remote interface (typically through the Internet Inter-ORB Protocol (IIOP)). (In this article, we don't discuss the separation of WEB or HTTP servers because it's not the main point of our attention).

The decision to deploy the architecture changes during the development of the Java EE application. As a result, developers may want to take advantage of the remote and local interfaces of the EJB to avoid loss flexibility. It is possible to develop a Java EE application that will accommodate any reasonable deployment topology without changing one line of source code, and the only change that needs to be made may be the deployment descriptor settings, which can greatly save developer time. It also makes sense to compare the performance of local and remote interfaces. Later, we will create a sample Java application that will enable us to easily transition from using the local interface to using the remote interface by setting the EJB's environment parameters. For All-in-one topologies, we will use local or remote interfaces to test sample applications in a controlled manner, and call them "all-in-one-all-local" and "All-in-one-all-remote", respectively.