Java 2 Enterprise Edition Architecture Overview
Java 2 Enterprise Edition Architecture Overview
Java 2 Enterprise Edition (J2EE) follows the General Web Architecture which was described on a separate page. As discussed in the evolution of Java, Java was initially touted as a strong client-side contender in the mid-1990s. However in the late 1990s, it evolved and gained much more acceptance as a solid middle tier tool. Over time, Sun added components to its middle tier solution (Servlets, EJB) until in mid-1999, Sun released its J2EE specification which provided a comprehensive view of the Java middle tier solution. Java solution providers have embraced J2EE which we will now explore.
J2EE uses a 4-level model for web development. The browser runs on the client displaying HTML and optionally runs JavaScript. The middle tier is comprised of two layers: a Presentation Layer and a Business Logic Layer. The data manages persistent data in a database and, where appropriate, legacy data stores.
J2EE implements the Presentation Layer with Servlets and, more recently, Java provides the option to generate webpages with dynamic content using JavaServer Pages (JSP). Servlets/JSP generate webpages with dynamic content (typically originating from the database). They also parse webpages submitted from the client and pass them to Enterprise JavaBeans for handling. Servlets and JSPs run inside a Web Server.
J2EE implements the Business Logic layer with Enterprise JavaBeans (EJB). Enterprise JavaBeans are responsible for logic like validation and calculations as well as provided data access (e.g. database I/O) for the application. Enterprise JavaBeans run inside an Application Sever.
Under J2EE, EJBs access a database through one of two means:
- using a JDBC interface which requires a lower level of coding and/or
- using SQLJ which provides a higher level interface to the database
In addition to these components for web application, J2EE provides for access by non-web clients to the business logic layer. A standalone Java application (IIOP client) can access an EJB directly using J2EE’s Remote Method Invocation (RMI) API.
Supporting J2EE APIs
J2EE provides a number of “supporting” APIs. The purpose of most of these APIs is to enable interaction between the “main” software layers/components in the J2EE architecture.
- Remote Method Interface (RMI)
- Java Naming and Directory Interface (JNDI)
- Java Message Service (JMS)
- Java Transaction API (JTA)
- Java Database Connectivity (JDBC) / SQLJ
- JavaMail /JMC
Remote Method Interface (RMI)
RMI is an important API used for supporting distributed computing and has been supported in core Java since version 1.1. RMI allows a Java client application to communicate with a Java server application by invoking methods on that remote object. With RMI, the client gets a reference to a server object and then it can invoke methods on that object as if it were a local object within the same virtual machine.
For server objects developed in other languages, you must employ other techniques like using Java IDL with CORBA or RMI/IIOP to access the server object.
Java Naming and Directory Interface (JNDI)
JNDI allows Java programs to use name servers and directory servers to look up objects or data by name. This important feature allows a client object to locate a remote server object or data.
JNDI is a generic API that can work with any name or directory servers. Server providers have been implemented for many common protocols (e.g. NIS, LDAP and NDS) and for CORBA object registries. Of particular interest to users of J2EE, JNDI is used to locate Enterprise JavaBean (EJB) components on the network.
Java Message Service (JMS)
JMS is an API for using networked messaging services. Data sent in a message is often intended as a sort of event notification (e.g. a Email-handling process may need to be notified when a request is enqueued). Another common use for messaging (thus JMS) is for interfacing with “external”, third party or legacy applications, typically via a Message Oriented Middleware product like IBM’s MQ Series (now WebSphere MQ). It can be complex/risky to use RPC/RMI to directly invoke remote applications while a messaging solution can provide a simpler and more reliable interconnection.
Java Transaction API (JTA)
JTA is used for managing distributed transactions (e.g. updates to multiple databases that must be handled in a single transaction). JTA is a low-level API and associated coding is complex and error-prone.
Fortunately, EJB containers (or application servers) generally provide support for distributed transactions using JTA. For this reason, the EJB developer is able to gain the benefit of distributed transaction while leaving the complex implementation details to the provider of the EJB container.
Java Database Connectivity (JDBC) / SQLJ
In principle, JDBC serves the same purpose as ODBC. JDBC provides a database-independent protocol for accessing relational databases from Java. JDBC supports Data Manipulation Language (DML) statements like insert, update, delete, select. It also includes Data Definition Language (DDL) statements like Create Table, Alter Table, etc.
JDBC was included in core Java starting with version 1.1. With JDBC, the SQL is always dynamically generated at runtime and sent to the database.
A easier-to-use industry standard for Java database access has emerged and is called SQLJ. SQLJ allows static SQL to be used and it requires less cumbersome syntax than JDBC. Other SQLJ advantages over JDBC include better code quality (due to compile-time syntax checking) and better performance (due to compile-time optimization). James Woodger co-authored an in-depth article on SQLJ for the November 2000 issue of Java Enterprise Developer.
JavaMail /JMC
JavaMail is an independent mail platform which works with major industry protocols (SMTP, POP3, etc.).
Source http://www.woodger.ca/jv_top.htm
Post a comment
RSS/XML