5.1.2 J2EE

J2EE is a standard. It is a specification for the application programmer interfaces and classes that an application server vendor must implement to adhere to the standard for enterprise-level server code. The emphasis is on "enterprise" in that the standard is designed for scalability, with two "containers" that manage threads and services for the Web and scalable business components, and numerous enterprise-level services.

J2EE consists of the following main components:

• A Web container to run multiple threads aimed at supporting Web users communicating with the application server using HTTP or HTTPS

  The Web container hosts and runs servlets; that is, Java code that takes a HTTP request, performs any necessary data retrieval and manipulation, and then returns a response. Servlet code is Java code that contains HTML output statements, or calls something else (Java Server Page, or JSP™) to produce the HTML output.

  The Web container also "hosts" JSPs. This is effectively the inverse of the previous point because JSPs are aimed at a different type of developer and can be thought of as HTML code that includes embedded Java.

  However, JSPs are compiled to a special case of a servlet at deployment or runtime, often using a component called Jasper. Jasper is the reference engine from

  Tomcat that Sun™ uses to verify application compliance with the JSP standard. Frameworks such as Struts and Java Server Faces (JSF) are built upon the JSP standard in combination with a servlet for control.

  Modern application servers, such as the WAS, may also use the Web container to host Web services supporting Apache Axis or JAX-WS with SOAP/XML over HTTP, or even portlets to produce page snippets designed to be hosted inside a page in a separate portal server. Under the covers, these are special cases of servlets.

  The J2EE reference engine for the Web container is Apache

  Tomcat, so if a J2EE Web application does not run in the WAS, then the

  Tomcat reference engine can be used to verify that the application is compliant with the standards.

• An Enterprise Java Bean (EJB) container that runs scalable business components

  A bean in Java is essentially a name for a component. Note, however, that a Java Bean and an Enterprise Java Bean are not the same thing, as explained here:

  A Java Bean is a component that uses specific naming for interfaces for getters and setters to hold logic and data in a form that allows runtime "reflection" to allow its use.

  An Enterprise Java Bean uses specific interfaces to allow it to be hosted within the EJB container. There are three main types of Enterprise Java Bean (EJB):

  The session bean is designed to host business logic rather than data. It offers a verb-based interface and set of methods, that is, "doXXXXX". Session beans should be stateless, but a special type of session bean, the stateful session bean, can be used with hand-crafted database calls or other code to host state or data. The entity bean is designed to represent a single instance of an entity, that is, a row in a database. Methods are available to determine which row the bean instance should represent, but an instance is essentially designed to be the host for data for a particular entity.

  Entity beans tend to have verb interfaces to determine the entity, but they map to nouns in their names and their fields. For example, "finder" methods are used to map the single instance from the pool of instances in a repository or database, and then fields are accessed by name.

  • In bean-managed persistence (BMP) entity beans, the developer is responsible for coding access to the raw data used to populate the entity bean.

  • In container-managed persistence (CMP) entity beans, the developer defines the type of data required using the SQL-like EJB Query Language (EJB QL) and lets the infrastructure sort out the most appropriate access mechanism to retrieve it.

    In Message Driven Beans (MDBs), a scalable listener to Java Message Service (JMS) message queues is produced.

  The EJB Container was originally designed to use the CORBA IIOP mechanism to access the beans remotely, and similar techniques for development of CORBA objects was required.

  Today, performance is better with local interfaces, but these remote interfaces led to the architecture.

  Essentially, the developer defines Java interfaces and some code and deployment descriptor configuration. Then, at deployment time, the container or deployment tool compile these to produce the code that actually runs. Just to emphasize: the code that actually runs as the EJB instances is derived from what was developed, but is generated at deployment time by the infrastructure.

  IBM was a contributor to the EJB container implementation, because many of the scalability ideas are based on or similar to those in CICS®.

  A useful standard application will use a remote interface for the session beans to allow access to the code running in the container, usually via a coarse-grained façade, and will then have fine-grained local interfaces for the other EJBs.

  J2EE also includes other standards that provide the underpinning for the rest of the application server:

• Java Message Service (JMS) provides message queuing interfaces similar to those in WebSphere MQ, which IBM uses for the underlying implementation or transport (depending on configuration).

  Java Database Connectivity (JDBC™) provides a standard interface for database access for SQL and stored procedures that are then mapped to the underlying technology by a specific driver for that DBMS implementation (that is, DB2, Derby, Oracle®, SQL Server® and so on).

• Java Naming and Directory Interface (JNDI) provides a means for "looking up" objects by a given name to map to its provided object implementation. This is often combined with Lightweight Directory Access Protocol (LDAP) servers.

• Java Connector Architecture (JCA), also known as J2C, is a mechanism for mapping to earlier or non-Java enterprise information sources. It is often used as the means by which JDBC requests are passed by the EJB container to a particular DBMS for maximum scalability, or to access CICS, IMS™, or applications such as SAP®. It requires a connector to map the interface to the Java world.

Next