Java Connectivity: Welcome to Java

Java comes with its own middleware for distributed programming called RMI (Remote Method Invocation). RMI is also the core middleware used by Enterprise Java Beans (EJB). Because RMI uses the CORBA/IIOP stack as transport layer, it is possible to use CORBA to interoperate with every distributed Java application (not only with genuine CORBA applications written in Java). This technology is based on the OMG Java-to-IDL mapping specification. J-Integra® Espresso's Java Connectivity feature supports this mapping (i.e. .NET code may interoperate with Java RMI applications in server or client mode).

A View on Java

Originally intended for embedded programming (named "Oak" at that time), Java was primarily designed for client side applications, specifically as the basis for "Applet" technology for use in the context of a web page.

Like its predecessors (mainly C++ and Smalltalk), Java is a pure object oriented language. It is strongly typed, has an efficient memory management system ("garbage collection"), and runs on top of the Java Virtual Machine (JVM). The specification of the JVM is public, and Java has subsequently been ported to a great variety of platforms. From the point of view of its basic structure, Java and C# are pretty similar.

With its second version ("Java 2"), Java was leveraged by some important enhancements, clearly targeting the server side:

• Java Database Connectivity (JDBC): for generic access to SQL databases
• Remote Method Invocation (RMI): for interprocess communication between several JVMs
• Java Beans: a simple component model which enhances Java classes with an inspection mechanism (mainly targeting developers of visual modelling tools);
• Java Servlet API: a Java based CGI replacement, enabling web servers to call Java classes hosted within a Servlet Engine without spawning a new process for each call.

The J2EE Architecture

The Java 2 Enterprise Edition (J2EE) is a broad collection of "enterprise level" APIs. Most of it is freely available from Sun. 3rd-party components are usually attached via Service Provider Interfaces (SPIs), using generic configuration mechanisms. Within J2EE, there are standard APIs for crypthographic algorithms, for transaction processing, for access to naming and directory services, for accessing Message Oriented Middleware (MOM), and messaging in general.

All these APIs are integrated within an embracing architecture, which is commonly associated with the term "Application Server" (or "AppServer" for short). An AppServer will usually be embedded within a 3 or 4 Layer Architecture:

The very core of the AppServer sitting in the center of this architecture is the EJB Server, hosting one or more EJB Containers (the EJB Server and EJB Containers are typically provided by the same vendor, so there is no clear demarcation between both). They provide a rich enterprise-oriented infrastructure for Enterprise Java Bean components. EJBs have some well-defined attributes:

• EJBs can be retrieved using a generic naming service implementing the Java Naming and Directory Interface (JNDI) API.
• EJBs can communicate via RMI, hence an AppServer may be transparently distributed over several JVMs and is therefore scalable.
• EJBs may work concurrently without being explicitly threadsafe, since the EJB Container takes care of all concurrency issues.
• EJBs may operate transactionally using a generic transaction service implementing the Java Transaction API (JTA). JTA is designed according to the X/Open XA standard interface. It therefore supports a standard 2-Phase-Commit protocol and is thus compliant with the OMG/CORBA Object Transaction Service. Usually, an EJB Server will provide its own implementation of a Java Transaction Service (JTS), but it may also support any other stand-alone Transaction Monitor.
• EJBs are configurable using standardized XML Deployment Descriptors which give, among other things, access to a declarative handling of transactional bean behavior, as well as a declarative handling of persistency and security issues.

The EJB 1.0 standard (the current version is 2.0) defined a pure EJB Architecture. The EJB Server did not host any other components than EJBs. So EJB was a mere middle-tier technology for providing business logic. Since EJB 1.1, Java Server Pages (JSP) allow spreading Java code snippets across an HTML page. The code snippets will be dynamically compiled into standard Servlets hosted by the web server's Servlet Engine. The J2EE Architecture allows integration of all components of a web application (EJBs, as well as Servlets/JSPs) within one hosting environment. The following is a short summary of the whole J2EE architecture:

• Business Logic: the EJB Container contains the EJBs, packaged within Java Archive (JAR) files.
• Presentation Logic: the Web Container contains web components (i.e. Servlets and JSPs) packaged within Web Component Archive (WAR) files.
• Data Logic: persistency will be provided by special beans within the EJB Container.
• Web Application: the whole web application (i.e. all the EJBs within its JARs, together with all the web components within its WARs) may be packaged within a single Enterprise Archive (EAR) file to be deployed to a J2EE Server.

Enterprise Java Beans (EJBs)

Behind J2EE, there is a fine grained component model (as opposed to the more coarse grained CORBA components). Though a CORBA component usually embraces a big chunk of business logic (most of the time a whole application on its own), Enterprise Java Beans prefer smaller components (e.g. a single account in a banking application may be represented by a dedicated 'Account EJB', and the process of generating a consolidated balance over a couple of accounts by a 'Balance EJB'). This concept leads to the following distinctions:

• Entity Beans: representing fine grained persistent entities. Depending on the preferred architectural pattern, they may contain also the business logic. There are two different ways to approach persistency with Entity Beans:
  • Bean Managed Persistence (BMP): where the Bean class itself is responsible for managing its persistency. Usually, a Bean will use JDBC to access the database.
  • Container Managed Persistence (CMP): where the Bean is made persistent using services of the hosting EJB Container (configured within the Deployment Descriptor).
• Session Beans: representing a (non persistent) chunk of business process functionality. Session Beans come in two different flavours:
  • Stateless Session Beans: offering atomar services to the client
  • Stateful Session Beans: realizing a dialogue with the client
• Message-Driven Beans: providing entry points to an asynchronous messaging service encapsulated within the Java Messaging Service (JMS).

A common problem with fine grained component models is the management of large amounts of similar objects (e.g. thousands of accounts within a bank application). Usually, one uses the approach of an explicit SELECT statement on a database table to retrieve the intended object. But this is not possible if the database access is encapsulated within a fine grained component (e.g. within an "AccountBean").

EJBs resolve this issue by using the "Home" pattern:

• Each bean (except Message-Driven Beans, which are anonymous endpoints for message queues) has a Home Interface. This Home Interface gives access to a couple of lifecycle management methods.
• Each bean has a Remote Interface representing its specific interface to the client (once an instance is retrieved using the Home Interface).
• Each bean has a Bean Class implementing the Remote Interface business functionality and the Home Interface's management methods.
• Each Entity Bean has a Primary Key Class representing its persistent identity.

The actual EJB will be generated from these classes (provided by the developer) within the (vendor specific) deployment process. Therefore, the Bean Class does not "syntactically" implement the Remote Interface (using Java's "implements" clause). There is only a rather weak syntactical connection between the parts of the bean.

During deployment, each bean's Home Interface will be registered with its name within a naming service. It can be retrieved by any (Java) client using the Java Naming and Directory Interface (JNDI). The Home Interface serves as a factory for the bean's instances. Once the client has access to the bean's Home Interface, it may create a new instance or (for Entity Beans) retrieve an existing instance.

J-Integra® Espresso and EJBs

Using J-Integra® Espresso, the standard EJB architecture may be accessed by Microsoft's .NET framework, thus allowing EJBs to be accessed by Microsoft's popular .NET presentation logic (which is tightly integrated into the most widespread client desktop platforms today).