J2EE.2.1 Architecture


The J2EE runtime environment consists of the following parts :

  • Application components . The J2EE programming model defines four application component types that a J2EE product must support:

    - Application clients are Java programming language programs that are typically GUI programs that execute on a desktop computer. Application clients offer a user experience similar to that of native applications, and have access to all of the facilities of the J2EE middle tier .

    - Applets are GUI components that typically execute in a web browser, but can execute in a variety of other applications or devices that support the applet programming model. Applets can be used to provide a powerful user interface for J2EE applications. (Simple HTML pages can also be used to provide a more limited user interface for J2EE applications.)

    - Servlets and JSP pages typically execute in a web server and respond to HTTP requests from web clients. Servlets and JSP pages may be used to generate HTML pages that are an application's user interface. They may also be used to generate XML or other format data that is consumed by other application components. Servlets, and pages created with the JavaServer Pages technology, are often referred to collectively in this specification as "web components." Web applications are composed of web components and other data such as HTML pages.

    - Enterprise JavaBeans (EJB) components execute in a managed environment that supports transactions. Enterprise beans typically contain the business logic for a J2EE application.

    These application components can be divided into three categories:

    - Components that are deployed, managed, and executed on a J2EE server. These components include JavaServer Pages, servlets, and Enterprise JavaBeans.

    - Components that are deployed and managed on a J2EE server, but are loaded to and executed on a client machine. These components include HTML pages and applets embedded in the HTML pages.

    - Components whose deployment and management are not completely defined by this specification. Application clients fall into this category. Future versions of this specification may more fully define deployment and management of application clients.

  • Containers. Containers provide the runtime support for the application components. A container provides a federated view of the underlying J2EE APIs to the application components. Interposing a container between the application components and the J2EE services allows the container to transparently inject services defined by the components' deployment descriptors, such as declarative transaction management, security checks, resource pooling, and state management. A typical J2EE product will provide a container for each application component type: application client container, applet container, web component container, and enterprise bean container.

    This specification requires that these containers provide a Java Compatible runtime environment, as defined by the Java 2 Platform, Standard Edition, v1.2 specification (J2SE). The applet container may use the Java Plugin product to provide this environment, or it may provide it natively. The use of applet containers providing only the JDK 1.1 APIs is outside the scope of this specification.

    The container tools also understand the file formats for packaging of the application components for deployment. The containers are implemented by a J2EE product provider.

    This specification defines a set of standard services that each J2EE product must support. These standard services are described below. The J2EE containers provide the APIs to access these services to application components. A future release of this specification will describe standard ways to extend J2EE services with connectors to other non-J2EE application systems, such as mainframe systems and ERP systems.

    Underlying the J2EE containers is the J2EE core. A J2EE product provider typically implements the J2EE server core using an existing transaction processing infrastructure in combination with Java 2 technology. The J2EE client core is typically built on Java 2 Platform, Standard Edition technology.

    Figure J2EE.2-1 illustrates the relationship of these components of the J2EE platform. Note that this figure shows the logical relationships of the components; it is not meant to imply a physical partitioning of the components into separate machines, processes, address spaces, or virtual machines.

    Figure J2EE.2-1. J2EE Architecture Diagram

  • Resource manager drivers. A resource manager driver (driver for short) is a system-level software component that implements network connectivity to an external resource manager. A driver can extend the functionality of the J2EE platform either by implementing one of the J2EE standard service APIs (such as a JDBC driver), or by defining and implementing a resource manager driver for a connector to an external application system (supported in a future release). Drivers interface with the J2EE platform through the J2EE service provider interfaces (J2EE SPI). A driver that uses the J2EE SPIs to attach to the J2EE platform will be able to work with all J2EE products.

  • Database. The J2EE platform includes a database, accessible through the JDBC API, for the storage of business data. The database is accessible from web components, enterprise beans, and application client components. The database need not be accessible from applets.

The J2EE standard services include the following (specified in more detail later in this document):

  • HTTP. The HTTP client-side API is defined by the java.net package. The HTTP server-side API is defined by the servlet and JSP interfaces.

  • HTTPS. Use of the HTTP protocol over the SSL protocol is supported by the same client and server APIs as HTTP.

  • Java Transaction API (JTA). The Java Transaction API consists of two parts:

    - An application-level demarcation interface that is used by the container and application components to demarcate transaction boundaries.

    - An interface between the transaction manager and a resource manager used at the J2EE SPI level (in a future release).

  • RMI-IIOP. The RMI-IIOP subsystem is composed of APIs that allow for the use of RMI-style programming that is independent of the underlying protocol, as well as an implementation of these APIs that supports both the J2SE native RMI protocol (JRMP) and the CORBA IIOP protocol. J2EE applications can use RMI-IIOP, with the IIOP protocol support, to access CORBA services that are compatible with the RMI programming restrictions (see the RMI-IIOP spec for details). Such CORBA services would typically be defined by components that live outside a J2EE product, usually in a legacy system. Only J2EE application clients are required to be able to define their own CORBA services directly, using the RMI-IIOP APIs. Typically such CORBA objects would be used for callbacks when accessing other CORBA objects.

    J2EE applications are required to use the RMI-IIOP APIs ( specifically the narrow method of javax.rmi.PortableRemoteObject ) when accessing Enterprise JavaBeans components, as described in the EJB 1.1 specification. This allows enterprise beans to be protocol independent. However, there is currently no requirement that enterprise beans be accessible using the IIOP protocol. Such a requirement will be added in a future version of this speci-fication. With this requirement, enterprise bean components will appear as CORBA objects.

  • JavaIDL. JavaIDL allows J2EE application components to invoke external CORBA objects using the IIOP protocol. These CORBA objects may be written in any language and typically live outside a J2EE product. J2EE applications may use JavaIDL to act as clients of CORBA services, but only J2EE application clients are required to be allowed to use JavaIDL directly to present CORBA services themselves . (As described above, a future version of this specification will require that enterprise beans appear as CORBA objects.)

  • JDBC . The JDBC API is the API for connectivity with database systems. The JDBC API has two parts: an application-level interface used by the application components to access a database, and a service provider interface to attach a JDBC driver to the J2EE platform.

  • Java Message Service (JMS). The Java Messaging Service is a standard API for messaging that supports reliable point-to-point messaging as well as the publish-subscribe model. This specification requires the JMS API definition to be available, but does not require any messaging service implementation to be available. A future version of this specification will require an implementation of both point-to-point messaging as well as publish-subscribe messaging.

  • Java Naming and Directory Interface (JNDI). The JNDI API is the standard API for naming and directory access. The JNDI API has two parts: an application-level interface used by the application components to access naming and directory services and a service provider interface to attach a provider of a naming and directory service.

  • JavaMail . Many Internet applications require the ability to send email notifications, so the J2EE platform includes the JavaMail API along with a JavaMail service provider that allows an application component to send Internet mail. The JavaMail API has two parts: an application-level interface used by the application components to send mail, and a service provider interface used at the J2EE SPI level.

  • JavaBeans Activation Framework (JAF). The JavaMail API makes use of the JAF API, so it must be included as well.

Many of the APIs described above provide interoperability with components that are not a part of the J2EE platform, such as external web or CORBA services. Figure J2EE.2-2 illustrates the interoperability facilities of the J2EE platform. (The directions of the arrows indicate the client/server relationships of the components.)

Figure J2EE.2-2. J2EE Interoperability



Java 2 Platform, Enterprise Edition. Platform and Component Specifications
Java 2 Platform, Enterprise Edition: Platform and Component Specifications
ISBN: 0201704560
EAN: 2147483647
Year: 2000
Pages: 399

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net