Java EE Architecture

The Java EE application program interface (API) consists of a suite of technology components and services that are used to build enterprise applications. It includes components that may be used to build presentation and business logic, APIs for managing business transactions, security and infrastructure tools to support the application operating environment, and tools for both internal and external integration. The following is a list of major technologies provided by Java EE. Refer to [J2EE15] pp 5-13 for more details (see also [J2EETutor] for additional information).

Enterprise Applications and Transactions

• Components Servlet, JavaServer Pages (JSP), Java Server Faces (JSF), and EJB are server-side components that are used to define presentation logic and business logic.

• HTTP The HTTP client-side API is provided by the java.net package, and the HTTP server-side API is defined using servlets and JSPs.

• HTTPS The same HTTP protocol runs over the SSL protocol by the same client and server API.

• JavaMail The mail API provides an application-level interface for application components to send Internet e-mails.

• Java Transaction (JTA) API The JTA API is intended to demarcate transaction boundaries between the container and the application to implement distributed transactional applications.

• Java Naming and Directory Interface (JNDI) JNDI API provides an application-level interface to access naming and directory services as well as a service provider interface to attach a provider of a naming and directory service.

• JavaBeans Activation Framework (JAF) JAF provides a framework for handling data in different Multipurpose Internet Mail Extension (MIME) types, originating in different formats and locations.

Security Services

• Java Authentication and Authorization Service (JAAS) Login context for authenticating and authorizing the serviced requester.

• Java Authorization Service Provider Contract for Container (JACC) Contract between a Java EE application server and an authorization service provider.

• Java Secure Socket Extension (JSSE) API for Secure Socket Layer that provides session security for data confidentiality, data integrity and server authentication.

• Java Cryptography Architecture (JCA) A basic framework for accessing and developing cryptographic functionality.

• Java Crypto Services (JCE) Cryptographic framework with advanced cryptographic functions to support multiple cryptographic service providers.

• CertPath or Certification Path API for creating, building, and validating digital certification paths.

• Java Generic Security Services Application Program Interface (JGSS) API for uniform access to security services atop a variety of underlying security mechanisms, including Kerberos, which are building blocks for single sign-on and data encryption.

Integration and Interoperability

• Java Message Service (JMS) JMS provides reliable messaging for both point-to-point and publish-subscribe messaging-oriented services.

• Remote Method Invocation over the Internet Inter-ORB Protocol (RMIIIOP) The API allows remote Java calls using RMI over IIOP, which can access CORBA objects or services from a Java RMI application directly.

• Java Interface Description Language (IDL) Java IDL allows a Java EE application to act as a CORBA client to invoke external CORBA objects using the IIOP protocol.

• JDBC API JDBC API provides connectivity with the back-end database systems, which includes connections, connection pooling, and distributed database services.

• Java EE Connector Architecture Connector Architecture is a service provider interface that allows resource adapters connected to Enterprise Information Systems (EIS) or legacy systems to be plugged in to any Java EE service components.

• Web Services This includes API support for synchronous Web services (Java API for XML-based RPC, or JAX-RPC), asynchronous Web services (SOAP with Attachments API for Java, or SAAJ), and access to XML registry servers (Java API for XML Registries, or JAXR). JAXP provides a standard way to parse XML documents and to transform those using stylesheets. Java EE 5.0 adds simpler and broader support for Web services by introducing JAX-WS 2.0 (successor to JAX-RPC) and JAXB 2.0. Refer to [J2EE15Intro].

Management

• Java Management Extensions (JMX) The JMX API captures application events and exceptions for application-level system management and diagnosis.

Figure 1-1 depicts the suite of Java EE technologies in a logical architecture diagram. Client applications can send service requests to the Web Container or EJB Container for accessing business transactions or services. The Web Container provides technologies for building Web-based applications and defining processing logic in the Web tier. The EJB Container provides technologies for building reliable business applications to manage reliable and scalable transactions. The security services are shared among the containers. The integration and interoperability technologies are used for both back-end system integration (such as legacy system and ERP system integration) and cross-platform interoperability (such as Java EE .NET interoperability).

Figure 1-1. Java EE 5.0 architecture

Java EE technologies support a variety of clients, for exampleJava EE: applet, Java ME client (or mobile devices), and application clients (browsers and rich clients). These clients can access different service components provided by the Java EE via HTTP protocol or secure HTTPS protocol using Secure Socket Layer (SSL) or Transport Layer Security (TLS). The Java EE consists of the Web Container (usually implemented as a Web server) and the Enterprise Java Bean (EJB) Container (usually implemented as an application server). A .NET client can also send service requests to the Web Container or the EJB Container via a variety of interoperability options such as Web services (which interoperate with JAX-RPC) and a bridge (which interoperates with RMI-IIOP).

Building Interoperable Components

Servlets, JSPs, EJBs and JSFs are programming language elements that can be used to build reusable components for interoperating with .NET or other platforms. Servlets and JSPs are usually categorized as Web components, as they are managed in a Web Container. For example, they can create Web services that can exchange business data synchronously or asynchronously with .NET applications. EJBs are categorized as EJB components, as they are managed in an EJB Container. For example, they can interoperate with a .NET application using an RMI-IIOP bridge. The underlying Java EE services are responsible to provide underlying system services and infrastructure functions for the Web tier (or Web Container) or business tier (or EJB Container) components while interoperating with a .NET application. For example, RMI/IIOP communication service is required when an RMI-IIOP bridge integration strategy is used.

The following provides a brief description of these programming language elements and the underlying Java EE services:

Servlets

Servlets are server-side Java programs that process business logic and handle HTTP requests and replies. A typical servlet is a Java class that extends HttpServlet. When the client submits a service request, a servlet receives an HTTP request (HttpServletRequest) and an HTTP response (HttpServletResponse) in the parameters using the doGet method. Data results or messages can be rendered as an HTML page by printing HTML tags of texts and data, for example, out.println("<html><body><p>Hello World, Java EE .NET Interoperability</p></body></html>").

Servlets will be deployed to a "context" (a virtual name for the servlets deployed) on the local host, for example, myContextRoot, and can be invoked via the URL http://localhost:8080/myContextRoot/myServlet where myServlet is the name of the servlet. The file web.xml stores information about the servlet configuration, where the actual Java class will be referenced to a physical Java class name (in this example, myServletClass) and the URL pattern (for example, /myContextRoot). The web.xml file is a deployment file, stored in the ./WEB-INF directory of the Web server or application server.

JSP

JSP is a Java scripting language that will be compiled dynamically into a servlet (and re-compiled again for any changes intelligently), and cached for better performance during execution. A typical JSP may consist of the following elements:

• Static HTML Content This is a normal HTML document, where the JSP compiler does not need compilation.

• Scripting Elements These are simple Java codes that are designed to handle presentation logic, rather than business logic.

• JSP Directives These are instructions for the JSP compiler to process, for example, to import Java classes into the page or to provide special handling instructions for the page when invoked.

• JSP Actions Actions are tags that control the runtime behavior of JSP and manage the responses returned to the client. Standard actions include useBean (instantiate and use the JavaBean in the JSP), include (include a file when the JSP is requested), setProperty (set the property of the JavaBean), getProperty (get the property of the JavaBean), param (provide the name and value of the parameter as additional information), forward (forward the requester to a new page), and plugin (generate client browser-specific HTML tags that result in invoking the Java Plug-in software codes).

• JSP Taglibs Taglibs are XML-like custom tags with optional attributes and bodies for a JSP. They can be used to perform simple data transformation, filter certain data content, or to conceal the complexity of accessing data sources and other Java objects. Using taglibs can make the processing logic more structured and easier to maintain in a single JSP and can be included in a JSP by adding a JSP directive <%@ taglib uri="/myTag" prefix="myPrefix" %>. The prefix denotes a tag library descriptor (for example, myTag.tld). The actual Java class is referenced in the web.xml with the taglib name and the physical URI location.

JSF

JSF is a draft specification (http://java.sun.com/javaee/javaserverfaces) for new standardized user interface components that manage page state, application events, input validation, and page navigation and that support internationalization and accessibility. It augments JSP technology by providing an interface to the custom tag library within a JSP page. It is also a good tool supporting a Model-View-Controller architecture such as Struts.

EJB

EJBs are reusable components that encapsulate business logic. They make use of the container services that manage the life cycle of the business objects, operate the naming service, and provide transaction handling (for example, connecting to multiple data sources), security mechanisms (for example, identifying the principals and the users), and persistence mechanisms.

There are three types of EJBs:

• Session Beans Session beans denote a conversation between the client application and the remote service component. When a client requests a business service by invoking a remote service component, the session bean (the remote component) replies. A stateful session bean may determine to persist the session state of the interactions or invocations between the client and the remote service components. If the session state is retained, the stateful session bean can better manage the transaction integrity or resume after the session fails over. This is usually achieved by using the container services such as Java serialization and Java reflection. A stateless session bean does not persist the session state.

• Entity Beans Entity beans synchronize the state with a persistence data store using the container services. In other words, business data can be persisted to the back-end database reliably and securely using entity beans. If developers explicitly design and specify how business data should be persisted in the database, then the entity bean is said to be bean-managed persistence. If developers make use of the container tools, which are provided by the application server vendor, to manage the object-relational mapping from the entity bean to the underlying relational database, then the entity bean is said to be container-managed persistence.

• Message Driven Beans (MDB) MDBs allow an EJB to receive a Java Message Service (JMS). In other words, an EJB can be the target of a JMS message. This can bring the benefits of providing reliable, asynchronous delivery of information from the client using JMS to the server using EJBor vice versa. Besides, MDB can be easily interoperable with other Java EE components using messaging and EJB.

Java EE 5.0 introduces EJB 3.0, which uses annotation (@Stateless, @EJB) to simplify the development complexity and effort in building EJBs. Refer to [J2EE15Intro] for examples and details.

Supporting Services for Interoperability

Java EE containers provide common services that are shared by Java EE components. These system services provide functions for database connectivity, transaction management, naming service, communication and connectivity, and messaging.

• Database connectivity service JDBC.

• Transaction management service JTA.

• Naming service JNDI.

• Communication and connectivity services HTTP, HTTPS, SSL, RMI / IIOP.

• Messaging service JMS, JavaMail.

Among these Java EE services, the communication and connectivity services are crucial to supporting Java EE .NET interoperability using the bridge technology (such as RMI/IIOP bridge). The Messaging service is often used for synchronous and asynchronous Web services integration strategy. For example, SAAJ requires JavaMail to handle document attachments.

Deploying Java EE Applications

Java EE applications are usually packaged and deployed in one or multiple units in EAR file format. An EAR file (depicted in the META-INF/application.xml file) consists of EJB components in JAR files (META-INF/ejb-jar.xml), Web modules in WAR files (WEB-INF/web.xml), and Java modules in JAR files (META-INF/application-client.xml). Many application server implementations allow developers to deploy Java EE applications by any of the following mechanisms:

• Dropping the EAR file into an auto-deploy directory (for example, %AS_HOME%\domains\domain1\autodeploy in Sun Java System Application Server where %AS_HOME% is the directory where the application server binaries reside).

• Using an ANT script to deploy (for example, Sun Java System Application Server uses a customized ANT script called asant).

• Using a Web administration console to deploy.

• Using a command line interface (for example, asadmin deploy in Sun Java System Application Server).

• Using an IDE such as NetBeans to deploy.

Figure 1-2 shows the structure of Java EE deployment elements (that is, deployment descriptors and the contents such as EAR and WAR files). A Java EE application can be packaged and deployed in an EAR file, which in turn can consist of multiple JAR files (Java classes) and WAR files (for Web applications). A Java EE .NET interoperable application written in Java, whether it uses synchronous communication, asynchronous messaging, or bridge integration strategies, is also deployed using the same deployment mechanism (say, EAR or WAR file) here.

Figure 1-2. Java EE application deployment structure

Management of access rights for security control is very important for application deployment. The security role is defined in the application.xml file, which is a declarative security feature of the Java EE architecture. An application deployment tool will copy all EAR files to the Java EE application server, generate any necessary implementation classes and help documentation, and deploy the application EAR files to the deployment directory of the Java EE application server. After that, architects and developers need to configure the application server-specific information, such as creating data sources and connection factories and administer JMS queue names.