Java 2 Enterprise Edition (J2EE)
J2EE is an on-going standard for producing secure, scalable, and high availability enterprise applications. The standard defines the services that must be provided by J2EE compliant servers. Services are provided by J2EE containers in which J2EE components will run. Further information on the J2EE specification and components can be found at http://java.sun.com/j2ee.
Although the J2EE specification defines a set of services and component types, it does not contain information on how to arrange the logical architecture into physical machines, environments, or address spaces.
The J2EE platform provides a common environment for building secure, scalable, and platform-independent enterprise applications. Many businesses are now delivering goods and services to customers via the Internet by using such J2EE-based servers. The requirements of such an environment demand open standards on which to build applications, for example,
Java 2 Platform, Standard Edition (J2SE), a platform independent language
Components that deliver Web-based user interfaces
Components to encapsulate business processes
Access to data in corporate data stores
Connectivity to other data sources and legacy systems
Support for XML, the language of B2B e-commerce
Components and Containers
J2EE specifies that a compliant J2EE application server must provide a defined set of containers to house J2EE components. Containers supply a runtime environment for the components. Application Programming Interfaces (APIs) in J2EE are available to provide communication between components, persistence, service discovery, and so on. J2EE application server vendors provide containers for each type of J2EE component:
Web Container
Web Services Container
EJB Container
There are three types of standard components deployed, managed, and executed on a J2EE Server:
Web components— A Web component interacts with a Web-based client, such as a Web browser. There are two kinds of Web components in J2EE—servlet components and JavaServer Page (JSP) components. Both types handle the presentation of data to the user and are described in Days 12, 13 and 14.
Web services— A Web component that exposes servlets and EJB components based on SOAP and HTTP protocols are described in Day 20 and Day 21.
EJB components— There are three kinds of Enterprise JavaBean components—Session beans, Entity beans, and Message-Driven beans. EJBs are described on Day 4, Day 5, “Session EJBs,” Day 6, “Entity EJBs,” and Day 10, “Message-Driven Beans” respectively, for further information.
Figure 1.4 shows the overall relationships between the different containers and components in the J2EE environment.
Figure 1.4. J2EE logical architecture.
J2EE Standard Services
Containers must provide each type of component with a defined set of services that are covered in detail as you progress through the book. Briefly these services consist of
Connectivity— Containers must support connectivity to other components and to application clients. One form of required connectivity is to distributed objects through both Java Remote Method Invocation (RMI) and CORBA (as implemented by the Java IDL package and RMI over IIOP). Internet connectivity must be provided both through the Hypertext Transport Protocol (HTTP) and its secure form (HTTPS).
Directory services— J2EE servers are required to provide naming services in which components can be registered and discovered. The Java Naming and Directory Interfaces (JNDI) provide a way of accessing these services.
Data access and persistence— Data access is provided through the Java Database Connection API (JDBC). This API enables both the application level to interface with databases and also service providers who build drivers for specific databases.
Legacy connectivity— The Java Connector Architecture (JCA or Connectors) provides J2EE support in integrating Enterprise Information Servers and legacy systems, such as mainframe transaction processing and Enterprise Resource Planning (ERP) systems. This support extends to J2EE service providers who are writing adapters to connect other systems to the J2EE enterprise architecture.
Security— Security is built into the J2EE model. APIs, such as the Java Authentication and Authorization Service (JAAS), assist the J2EE enterprise application in imposing authentication and authorization security checks on users.
XML Support— The JAXP API supports the parsing of XML documents using Document Object Model (DOM), Simple API for XML (SAX), and the XML Stylesheet Language for Transformation (XSLT).
Transactions— A J2EE server must provide transaction services for its components. The boundaries of transactions need to be specified by the container or the application. The container will usually take responsibility for transaction demarcation, although the Java Transaction API (JTA) allows the component to control its own transactions if required.
Web Services— Support for defining and using Web Services supporting the industry standard protocols such as Simple Object Access Protocol (SOAP), Universal Description, Discovery and Integration (UDDI) and Web Service Description Language (WSDL). J2EE containers must support the Java API for XML Messaging (JAXM), Java API for XML-based RPC (JAX-RPC), Java API for XML Registries (JAXR), and SOAP with Attachments API for Java (SAAJ) APIs.
Messaging and email— The Java Message Service (JMS) allows components to send and receive asynchronous messages, typically within an organizational boundary. The JavaMail API enables Internet mail to be sent by components and also provides functionality to retrieve email from mail stores. JavaMail uses the JavaBeans Activation Framework (JAF) to support various MIME types.
Figure 1.5 shows the J2EE architecture updated with the services available to its containers. All of these services are discussed in more detail tomorrow.
Figure 1.5. The J2EE platform with services available.
Every J2EE-compliant server must support the services defined in this section. To provide a concrete example of how services should work, the team working on the J2EE Java Specification Request (JSR) is responsible for providing a Reference Implementation (RI) of the J2EE APIs. This RI is freely available from Sun and provides a convenient platform for prototyping applications and testing technologies. The J2EE Reference Implementation (J2EE RI) is described in Day 2, “The J2EE Platform and Roles”.
New Features of J2EE 1.4
The main changes introduced for J2EE 1.4 are
JSP 2.0 Element Language (EL)— covered on Day 13
JavaServer Pages Standard Tag Library— covered on Day 14
Smaller changes were made to incorporate the
J2EE Blueprints
The J2EE Blueprints are a set of best practices that show how best to implement J2EE applications. The Blueprints provide a concrete implementation of Sun's vision for 3-tier, J2EE-based systems. These can be found online at http://java.sun.com/j2ee/blueprints.
Here you will find example online e-commerce application. The best practices covers application design and, in particular, the promotion of the following:
Code reuse
Logical functional partitioning
The separation of areas of high maintenance
Extensibility
Modularity
Security
Simple and consistent user interface
Efficient network usage
Data integrity
The J2EE Blueprints guide you through the design process of J2EE applications, discussing the following topic areas:
The Client Tier
The Web Tier
The Enterprise JavaBeans Tier
The Enterprise Information Systems Tier
In addition, there are discussions on how to package and deploy your enterprise applications.
J2EE Compatibility and Java Verification
To enable Enterprise service providers to test their products against the specification, Sun Microsystems Inc. offers a testing environment. Servers that pass all of the tests can be certified as J2EE compliant. Further details of the Java Application Verification Kit (AVK) can be found online at http://java.sun.com/j2ee/verified/index.jsp. A list of certified application vendors' servers can also be obtained from this web site.