This article provides a high-level introduction to J2EE. It is taken from chapter one of the book Beginning J2EE 1.4 From Novice to Professional, written by James L. Weaver, Kevin Mukhar, and Jim Crume (Apress, 2004; ISBN: 1590593413).
The World Wide Web is becoming an increasingly prevalent backbone of business applications. The end points that provide web applications with server-side business rules are considered “web services.” The W3C consortium, in an effort to unify how web services are published, discovered, and accessed, has sought to provide more concrete definitions for web services:
“A web service is a software system identified by a URI, whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the web service in a manner prescribed by its definition, using XML-based messages conveyed by internet protocols.”
XML is used to publish the description of the services.
Those descriptions are discoverable through some form of registry.
XML messages are used to invoke those services and to return the results to the requestor.
The W3C has established Web Service Description Language (WSDL) as the XML format that is used by web services to describe their services and how clients access those services. In order to call those services, clients need to be able to get their hands on those definitions. XML registries provide the ability to publish service descriptions, search for services, and obtain the WSDL information describing the specifics of a given service.
There are a number of overlapping XML registry service specifications, including ebXML and Universal Description, Discovery, and Integration (UDDI). The JAXR API provides an implementation-independent API for accessing those XML registries.
Simple Object Access Protocol (SOAP) is the lingua franca used by web services and their clients for invocation, parameter passing and obtaining results. SOAP defines the XML message standards and data mapping required for a client application to call a web service and pass it parameters. The JAXRPC API provides an easy-to-use developer interface that masks the complex underlying plumbing.
Not surprisingly, the J2EE architecture provides a container that hosts web services, and a component model for easily deploying web services. Chapters 12 and 13 in the book cover SOAP and web services.
One of the basic requirements of enterprise applications is the ability to allow multiple users of multiple applications to simultaneously access shared databases and to absolutely ensure the integrity of that data across those systems. Maintaining data consistency is no simple thing.
Suppose that your application was responsible for processing bank deposits, transfers, and withdrawals. Your application is processing a transfer request from one account to another. That process seems pretty straightforward: deduct the requested amount from one account and add that same amount to the other account. Suppose, however, that immediately after deducting the sum from the source account, something went horribly wrong—perhaps a server failed or a network link was severed—and it became impossible to add the transfer to the target account. At that point, the data’s integrity has been compromised (and worse yet, someone’s money is now missing).
Transactions can help to address this sort of problem. A transaction represents a set of activities that collectively will either succeed and be made permanent, or fail and be reverted. In the situation described above, we could define the transaction boundaries to start as the transfer amount is withdrawn from the source account, and end after the target account was updated successfully. When the transaction had been made successfully, the changes are committed. Any failure inside of the transaction boundary would result in the changes being rolled back and the account balances restored back to the original values that existed before the start of the transaction.
J2EE—and EJB in particular—provides substantial transaction support. The EJB container provides built-in support for managing transactions, and allows the developer to specify and modify transaction boundaries without changing code. Where more complex transaction control is required, the EJB can take over the transaction control from the container and perform fine-grained or highly customized transaction handling.
Security is a vital component in enterprise applications, and J2EE provides built-in security mechanisms that are far more secure than home-grown security solutions that are typically added as an afterthought.
J2EE allows application resources to be configured for anonymous access where security isn’t a concern. Where there are system resources that need to be secured, however, it provides authentication (making sure your users really are who they say they are) and authorization (matching up users with the privileges they are granted).
Authorization in J2EE is based on roles of users of applications. You can classify the roles of users who will be using your application, and authorize access to application components based on those roles. J2EE provides support for declarative security that is specified when the application is deployed, as well as programmatic security that allows you to build in fine-grained security into the Java code. These security mechanisms are discussed in the online chapter that comes as part of the download package for this book, available from the Apress web site at http://www.apress.com.
Sample J2EE Architectures
There is no such thing as a single software architecture that fits all applications, but there are some common architectural patterns that reappear frequently enough to take note of. The following architectures are ones that you’re likely to run into as you examine and develop J2EE-based systems.
Each one of these has its own merits and strong points. I present them here to illustrate that there are a number of ways to put together applications and as a short “field guide” for identifying these architectures as you spot them in the wild.
n-Tier application architecture is intended to address a number of problems, including:
High cost of maintenance when business rules change
Inconsistent business rule implementation between applications
Inability to share data or business rules between applications
Inability to provide web-based front ends to line-of-business applications
Poor performance and inability to scale applications to meet increased user load
Inadequate or inconsistent security across applications
Two tier applications address sharing of data between applications and, to a lesser degree, touch on performance scalability, but do not address any of the other concerns. The business rules still must be coded into the client applications, leaving the problems of high maintenance costs and inconsistency in business rules and security.
J2EE provides a platform that enables developers to easily create n-tier applications in a number of different configurations. The following examples illustrate some typical J2EE application configurations.
Application Client with EJB
The client application is built as a stand-alone (JFC/Swing or console) application. The application relies on business rules implemented as EJBs running on a separate machine.
JSP Client with EJB
The client in this architecture is a web browser. JavaServer Pages access business rules and generate content for the browser.
Applet Client with JSP and Database
Again, the client application is a web browser, but in this case a Java applet is used within a web page to provide a more interactive, dynamic user interface for the user. That applet accesses additional content from JSPs. Data is accessed from the JSP via the JDBC API.
Using Web Services for Application Integration
In this final example, a client application implemented in C# accesses data from a web service implemented in Java.