| The goal of J2EE is to provide an enterprise-quality platform that is highly available, scalable, flexible, secure, interoperable, portable, and independent of machine or network architecture and vendor-specific software. J2EE also makes it practical to develop and maintain enterprise applications that are significantly less complex or costly than their predecessors. Throughout the remainder of this appendix, you will see how Sun has been able to achieve its objectives. The Major Components J2EE applications are made up of components. The J2EE runtime environment defines four types: Application clients Running on a desktop system, these clients look and behave like native applications. As such, they typically have graphical user interfaces (GUI) created using the Swing or Abstract Windowing Toolkit (AWT) APIs, but may also have command-line interfaces. However, unlike applications that do all the work at the desktop, they interact with other enterprise components to do their work. Applets Web browser-based GUI components that are often significantly more "lightweight" than an application client. Applets are written in the Java programming language and execute in a Java Virtual Machine installed in the Web browser. Applets themselves are not installed, but are delivered as part of the content included in a Web page. They usually perform fewer functions than an application, and are often limited to providing a rich user interface while leaving much of the computing work to other enterprise components. Unless the host system explicitly provides permission, applets are restricted from performing operations that may be harmful, such as writing to the filesystem. Applets are frequently designed to limit their use of memory and resources, and are therefore suitable for devices that have limited capacity. Web These components interact with Web servers to respond to HTTP requests from clients. Java Server Pages (JSP) and servlets receive requests from, perform functions for, and often return responses to their clients. JSPs are text files made up of markup and Java code that are compiled into and execute as servlets. JSP provides a more natural way for developers to work with dynamic content. JSPs and servlets often produce HTML pages that are the user interface for an application. They might also produce XML for consumption by their clients. Web components interact with other enterprise components to do their work. Enterprise JavaBeans (EJBs) Enterprise JavaBeans contain the business logic of an enterprise application. A significant amount of support to satisfy enterprise requirements is built into these components and their runtime environment. For example, EJBs and their containers transparently manage transactions, security, and concurrency. EJBs are distributed components clients can interact with EJBs that do not reside in the same process or machine space. Furthermore, J2EE provides interoperability with EJBs by permitting clients to interface with them in languages other than Java through CORBA. Eventually, clients will also be able to access EJBs through the Simple Object Access Protocol (SOAP). EJBs interact with other EJBs and components to perform their work. In J2EE, as in other programming models, a component is more than a type for functionally similar pieces of software. Clemens Szyperski defined software components as "binary units of independent production, acquisition, and deployment that interact to form a functioning system." The components of J2EE adhere to this definition. J2EE components are compiled programs written in the Java programming language. They are self-contained software units that can be constructed or purchased independently of other components, assembled to produce a J2EE application, and deployed to J2EE servers. J2EE components implement interfaces defined by the J2EE specification, so they are portable between compliant J2EE servers. Components help realize some of the goals of enterprise computing by providing high quality interchangeable pieces that are constructed by domain experts. Like pieces of a modern automobile, components can realize the economic benefits of competition or economies of scale, and also benefit from what has been learned from a century of manufacturing practice. J2EE components consist of one or more class files and an associated file that declaratively defines the extrinsic behavior of the component. For example, an EJB is comprised of an enterprise bean class, supporting classes, resources, interfaces, and a file (called a deployment descriptor) that defines how the component will be deployed to and then managed by the runtime environment. This is all packaged together into a Java archive (JAR) file, which is then installed into a container that provides the runtime support for the various types of components described previously. Containers Containers are an essential part of J2EE. At a bare minimum, containers provide a compatible runtime environment as defined by the J2SE specification. Even this minimal container has an impressive list of features. The environment is platform-neutral, secure, and has been designed from the ground up to support network-aware and mobile components. It provides support for fault tolerance and concurrency, and efficiently manages computing resources such as memory by automatically discarding unused objects. Each component type has a container that provides support for the unique functions the component performs. In other words, there are containers for application clients, applets, Web components, and Enterprise JavaBeans: Application client containers provide J2SE runtime support and access to J2EE APIs. Applet containers provide specialized methods for locating and retrieving applets in a system of networked machines, invoking applet methods, interacting with Web browsers, and providing a protected environment for applets to run in. Web containers, sometimes called servlet or JSP engines, receive requests and compose and transmit HTTP responses. A Web container determines which component should receive a request, creates or obtains an instance of that component, and passes control to it. Information about the mapping of a URL to a Web component is contained in a deployment descriptor, as is information about the way sessions should be handled or which error pages to display. Among many other things, Web containers free developers from tracking session states, managing HTTP connections, and creating, destroying, or otherwise managing the lifecycle of component objects. EJB containers are the most sophisticated of the containers defined by J2EE, as they perform many advanced functions. Their sophistication also derives from the complexity of the interactions between EJBs and the container. Fortunately, developers are shielded from most of the complexity. Because Enterprise JavaBeans can be distributed between processes or machines, the EJB container must provide facilities for clients to remotely access them. The container also manages the creation and destruction of component instances, and often persists instance data to or retrieves it from a database. Among the most valuable functions, EJB containers can guarantee that a sequence of activities occur together, or take corrective action when they do not. Web and EJB containers perform many of the same functions. These containers extend the basic capabilities of the minimal container defined by J2SE to meet the requirements of enterprise applications. They both perform advanced object lifecycle management, and can pool ready-made instances of components in anticipation of demand. When the demand for a particular kind of component decreases, containers can "throttle back"; reducing the number of available objects and thereby conserving system resources for use by other software. They also manage concurrency by safely permitting multiple clients to use the same bean simultaneously, or by creating instances that are dedicated to serving a particular client. Finally, they perform authentication and authorization, securing components or other resources from unauthorized use. Much of the functionality described is available without including special code in the components to perform all these useful functions. The configuration of the component, as described in the deployment descriptor, determines what behavior supplements the built-in functions of the component. This greatly simplifies the development of the component, and permits the developer to focus on the business logic of the component. As a result, enterprise applications using J2EE can be less costly to produce, and have higher quality all the container functions have already been well tested. You might have noticed that clients interact with components through containers. For example, HTTP requests are passed to the container for delivery to a Web component. Clients of Enterprise JavaBeans find the beans they are interested in and invoke methods that "pass through" the EJB container, so that the container can manage transactions or concurrency. When one thinks of all the support that a container lends a component, it is easy to see why a container is so intimately involved with its components. By design, containers have well-defined and standard open interfaces for interacting with components and component clients. The behavior of containers is also openly documented. Containers improve interoperability, and because they support a Java-based runtime environment, they also satisfy portability requirements. As you can see, J2EE containers and components provide many of the functions required to deliver enterprise-quality applications. J2EE-compatible containers also provide APIs that components use to access a standard set of services. Note As mentioned earlier, it is not possible to provide a detailed look at each of the components mentioned in this section. However, there are a number of good books about Java, applets, JSPs, servlets, and Enterprise JavaBeans that can help you get up to speed. Also, Sun hosts several Web sites for Java developers. Specifications, reference implementations, tutorials, and white papers are all available without cost. See http://www.javasoft.com and http://developer.java.sun.com.
The Services Provided Over years of development, Sun has produced specifications and implementations of APIs for a number of useful enterprise-level services. The current J2EE specification defines which APIs are required as standard services for a J2EE-compatible platform implementation. These services support the application components reviewed earlier: HTTP/HTTPS Clients that want to communicate using HTTP or HTTPS use the J2SE java.net package and the javax.net.ssl extension package. These APIs permit one to establish connections, receive requests, and produce responses. Using HTTPS adds the capability of performing secure communication using the Secure Sockets Layer (SSL), or the newer Transport Layer Security (TLS). The servlet and JSP component APIs define the server-side interface. Java Transaction API (JTA) This application programming interface provides support for demarcating boundaries around methods. The boundaries signify the beginning and end of a series of operations that must be completed together. Collectively, the series of operations are called a transaction. Components can manage transactions themselves by using this API, but often designers permit containers to manage transactions on behalf of the component. The API provides the interface between a transaction manager, which has the low-level responsibilities for transactions, and a resource manager that handles resources available to the application that are transactionable. A database server or messaging system is an example of a resource manager. Transaction managers work with applications and one or more resource managers to extend the transaction capabilities of a resource manager to the application in a portable way. RMI-IIOP The APIs that compose this subsystem permit components or other software to communicate with objects that are not part of the local execution context. RMI (Remote Method Invocation) enables a programmer to use an object as though it were locally created without having to understand complex protocols, or difficult programming. Java programmers can quickly build distributed applications using RMI, without having to learn an Interface Definition Language (IDL) or its mappings. "Native" RMI for J2SE is based on the RMI Transport Protocol, which uses a combination of HTTP and object serialization to invoke methods and return data. Naturally, this kind of communication depends on features that are present in the Java runtime environment as such, it is proprietary. To meet the interoperability goals for enterprise applications, RMI can also be used with the Internet Inter-ORB Protocol (IIOP) as the underlying transport. IIOP is a part of the Object Management Group's (OMG) CORBA family of specifications and is based on open standards defined with the participation of hundreds of vendors and users. The use of IIOP and RMI-IIOP makes it possible for J2EE applications to access CORBA services that are external, or for external CORBA objects to use EJBs. Because CORBA is language-neutral, application components written in C, C++, Smalltalk, or other languages that provide CORBA bindings can communicate with J2EE applications. Java IDL J2EE applications use Java IDL to act as clients of CORBA services. Like RMI-IIOP, Java IDL allows Java applications to invoke methods on remote objects. Java-IDL adds CORBA-capability to the Java platform using the industry standard OMG IDL and IIOP. Programmers develop applications using CORBA IDL to define interfaces and an IDL compiler to produce Java versions of the interfaces. On the other hand, the APIs for RMI-IIOP, while permitting interaction with CORBA services, permit developers to work completely in the Java programming language. Java Database Connectivity (JDBC) This API is used to connect to and work with relational database systems. J2EE applications can make connections to systems and query, update, or manage data. JDBC applications can use SQL to perform queries. A Service Provider Interface (SPI) enables the J2EE platform to make use of drivers that are designed to access vendor-specific RDBMS. Java Message Service (JMS) Supporting interfaces to enterprise messaging via message-oriented middleware (MOM) products, JMS enables J2EE clients and applications to send messages to other systems and each other. You can think of this as email for applications. Chapter 11, "Developing P2P Applications using J2EE, J2SE, and J2ME," introduced you to the concepts of JMS and presented an example of a simple JMS application. Java Naming and Directory Interface (JNDI) Enterprise computing applications and resources are frequently distributed across machines and can be separated geographically. Naming and directory services are used to associate user-friendly names and attributes with objects so that it is easier to locate them. By going to one of these services, a client can provide the service with a name and obtain a reference to an object, or an object itself. Directory services are typically more capable than naming services. Directory services can associate attributes, in addition to names, to objects and also support sophisticated searches. JNDI provides a standard API for naming and directory service access. JNDI is independent of any specific naming or directory service implementation. A service provider interface attaches a provider, which keeps track of the names, attributes, and objects, to the API. JNDI service providers give access to many different kinds of systems, including filesystems and a variety of existing naming and directory services, such as LDAP, DNS, NDS, and NIS, and the Windows Registry. JavaMail Most enterprise applications interact with people. In some cases, a client or application will need to send email to a person to notify her about status, or perhaps to invite her to perform a step that cannot be done by the application itself. The JavaMail APIs provide a platform- and protocol-independent means to send and receive email. An SPI is defined so that vendors can integrate their products as providers to JavaMail's vendor-neutral API. JavaBeans Activation Framework (JAF) The JavaBeans activation framework is used by the JavaMail API to provide dynamic handling of mail content. MIME types identify the content type(s) associated with a particular piece of mail. JAF identifies and creates objects to process different content types. Java API for XML Parsing (JAXP) Although there are several useful standards and implementations for processing XML documents, each implementation has unique methods for instantiating parsers, processors, or documents. Parsers also vary in how processing options are set or retrieved. JAXP provides a well-defined API that works with the SAX and DOM APIs to standardize parser and document creation. Similarly, JAXP standardizes the methods to create and invoke XSL processors. JAXP provides facilities for developers to plug in implementations of their choice. The reference implementation provides Apache's Crimson Parser and Xalan XSLT processor. Java Authentication and Authorization Service (JAAS) J2EE applications can use JAAS to authenticate users and implement access controls. JAAS performs security-related functions, such as authentication by password validation, independent of the underlying authentication technology. Security providers create implementations of authentication services that are "plugged into" the JAAS framework. Applications using JAAS can reuse enterprise-wide authentication services such as Kerberos, or an NT Domain. J2EE Connector Architecture Frequently, a company has already made or will make a significant investment into Enterprise Information Systems (EIS) that are integral to their business. To accommodate the integration of data and functions of those systems into J2EE applications, Sun has defined the connector architecture. The connector architecture defines system-level interfaces and behaviors (called system contracts) between a J2EE application server and a resource adapter, which acts as an intermediary for the EIS. These contracts provide support for the underlying mechanisms that enable transactions, security, and connection management, including resource pooling, in the J2EE environment. The connector architecture also defines a Common Client Interface (CCI) that is used for clients to programmatically interact with an EIS through a resource adapter, using a generic function-call/return-results model. Once a resource adapter has been written, the functionality offered by the EIS is treated as a natural extension to the standard services offered by a J2EE application server. As you can see, J2EE provides a rich set of standard services that avoid vendor lock-in through useful, open APIs. The J2EE Application Server J2EE application servers provide important support for enterprise applications. Besides hosting the various server-side containers, J2EE servers make it possible to easily deploy and manage components and applications. J2EE servers manage global resources, such as database and network connections and naming services. Finally, they also provide a secure operating environment. Although not required by the J2EE specification, most are capable of distributing their work to balance the load or provide fail-over support through clusters of servers. J2EE's features make it possible to develop capable networked enterprise applications with only the addition of a database to store persistent business data. Yet, J2EE strives for interoperability with other enterprise applications by adopting standards for communicating with other systems (TCP/IP, HTTP, and HTTPS), for interacting with other applications (CORBA, including IIOP), and for exchanging information (HTML, XML). Through the use of the connector architecture, it invites other enterprise information systems to participate in presenting a federated view of information and services to applications. With J2EE, Sun has raised the standard for enterprise-capable platforms. |
