1.2 Enterprise Java Technology

The three- tier computing model, represented in Figure 1.4, is well established in the computing industry. In fact, this model has been generalized into an n -tier model to handle some of the more sophisticated environments that have evolved.

Figure 1.4. Three-Tier Computing Model

The important question is, How does Java technology fit into a multitier computing model? As previously described, Java technology can run in all the tiers. However, what is more important to recognize is that to develop an application, it is not necessary that the technology run in all the tiers; nor is it required that all the computing platforms across the tiers use the same software or hardware architectures. It is quite likely that some of the tiers will not be written using Java-based technologies. Because of the Java set of interoperable technologies, it is possible to write a Java-based application for one or more of the tiers and interface to existing technologies in the same or other tiers.

Enterprise Java applications can connect to other non-J2EE application systems, such as mainframe and enterprise resource planning (ERP) systems. This capability can be achieved through the functionality offered by the Java Connector Architecture (JCA). ^[1] JCA allows resource adapters , or connectors , including JDBC and JMS drivers, to provide access to non-J2EE systems. These adapters can be plugged into any J2EE environment.

^[1] Unfortunately, the acronym JCA is also used to indicate another technology: the Java Cryptography Architecture. We will spell this acronym out whenever it is not clear from the context which technology it refers to.

• A servlet in the middle tier uses a JDBC connector to access a database and send the result to an HTML- or XML-enabled client.

• A company's C-based application can send a Web Services XML document through an existing message-queuing-based system, such as IBM WebSphere Message Queuing (MQ). ^[2] The XML document drives a set of servlets and EJB components , resulting in e-mail being sent to customers to notify them of a set of the company's new services.

  ^[2] Formerly known as IBM MQSeries.

• The client and the middle tier use non-Java technologies, whereas the data-base stored procedures in the back-end server are written in Structured Query Language for Java (SQLJ).

• A Java-based client application can be written to drive non-Java-based Web servers or databases.

• A non-Java-based system can send messages via a wireless communication service to a Java-based application running in a cell phone or a personal digital assistant (PDA).

Connecting heterogeneous applications and systems written in different languages and running on different platforms is one of the most complex tasks that enterprises face. To address the issues in this space, the emerging Web Services technology views resources and applications as services. These services can be accessed through a combination of language- agnostic message format over a transport protocol. Such a combination is called a binding . A popular binding consists of sending Simple Object Access Protocol (SOAP) messages over HyperText Transfer Protocol (HTTP). SOAP is a proposed standard format for exchanging business messages between applications using standard Internet technologies.

To summarize, it is clear that Java technologies can interoperate with any of the computing tiers in the enterprise. Therefore, the important question is not so much, "How does Java technology fit into a multitier computing model?" but rather, "Which Java technologies are most appropriate for your enterprise and where?"

1.2.1 The Middle Tier: Servlets, JSP, and EJB

When the Web-based computing environment was emerging, developing content that extended beyond static HTML pages was difficult, particularly when more than one vendor's Web server was involved. Extending the server with scripts often required the use of proprietary APIs, making the scripts written for one Web server incompatible with other Web servers. For a variety of reasons, the number of Web servers and proprietary APIs has been greatly reduced. Even so, without portable scripting languages, developing portable extensions to Web servers remained challenging.

The original Common Gateway Interface (CGI) programming model for Web servers was problematic from both scalability and security perspectives. Simple HTTP servers did not support multithreading. CGI scripts were a target of hackers; poorly designed and tested CGI programs failed to test parameters and passed them on to the remainder of the CGI program, resulting in buffer overflows that crashed the CGI script or the HTTP server itself. In some cases, the malicious request caused rogue code to get installed and executed in the server.

The emergence of the Java Servlet programming model simplified server-side Web server programming. Servlets offer server application developers a useful set of APIs for Web application development. In fact, servlets, which are written in the Java language, are often portable across a number of WASs and operating systems. Through servlets, it is possible to write platform-neutral scripts that can call enterprise beans; handle database transactions via JDBC; send messages via JMS and e-mail via JavaMail; generate output, such as HTML or XML, to send to the client; call other servlets; or perform other computing tasks. The servlet container ” the Web server component responsible for running and managing servlets through their life cycle ”also performs optimizations. For example, the servlet container can provide servlet pooling , which reduces the overhead of servicing a Web request by pooling instances of servlets so that a servlet is ready to be dispatched as soon as a Web service request arrives. Additionally, the container can provide sharing of HTTP session state across servlet invocations.

The Java Servlet API and runtime simplify writing Web applications and also improve security. As described in Part II of this book, much of the authentication and authorization processes are also now handled by the servlet container through its declarative security architecture, which reduces the burden on the application developer when developing or updating an application. Because the security services are part of the servlet architecture, many of them are easy to enable. For example, the servlet deployment descriptor ” an XML file containing instructions on how to run servlets ”can specify that communication to a particular servlet via HTTP requires confidentiality. The Web server and the servlet container will require that a client communicate with that particular servlet via an HTTP over SSL (HTTPS) session, which uses SSL for encryption. If the deployment descriptor specifies a requirement for client-side authentication based on a digital certificate, the digital certificates exchanged to establish the SSL session will be used to perform client authentication.

Although experienced software developers understand the business logic required to create enterprise applications, the details of how to correctly implement this sort of sophisticated security are often beyond their expertise. Even developers who do have some experience with security technologies do not always implement and deploy these security technologies in a secure manner. It is the responsibility of the Web server and the servlet container to correctly implement and integrate these technologies. By doing so, the security burden on the application developer is greatly reduced.

Servlets have been a boon to Web application developers. However, developing new content could be tedious , particularly when the result to be sent to the client is in HTML, XML, or other formats. The JSP technology was created to address this shortcoming. Rather than writing explicit code to produce the HTML or XML content that will be sent back to the client, a compiler converts an HTML, XML, and Java mixed-content file into a servlet that is then executed.

The servlet and JSP programming models are quite flexible and may be, relatively speaking, long running. However, many enterprise applications often require high throughput, scalability, and multiuser secure distributed transaction processing. The EJB model was created to address this need. Just as servlets run on a servlet container, EJB components run on an EJB container , designed to reduce the burden on application developers by providing a set of services common for transaction-based applications. These services include sophisticated distributed transaction management and security. Unlike the servlet and JSP programming model, however, the EJB programming model has additional constraints. For example, EJB components are single threaded, and they may not read from the file system. All I/O operations are intended to be via transactional subsystems using Java connectors, including database I/O operations via JDBC and messaging I/O operations via JMS. Exceptions to this rule are e-mail via JavaMail and printing. Specifically , EJB components are not to manipulate threads and perform file I/O and GUI operations. At first glance, this limitation may seem overly restrictive when compared to servlets and JSP files. However, these restrictions have an advantage in attempts to perform optimizations that result in overall improvements in transaction throughput and scalability. In many regards, this programming model is similar to the IBM Customer Information Control System (CICS) programming model used by large corporations for high-performance transaction processing. In fact, IBM supports the EJB programming model in CICS.

Like servlets and JSP, an EJB component uses a deployment descriptor to define its transaction characteristics, identify other enterprise beans that it will be calling, and specify the security requirements for calling its methods. The security part of the deployment descriptor focuses on authorization issues: specifically, which security roles are allowed to call the methods in an enterprise bean.

1.2.2 Component Software: A Step in the Right Direction

One of the most difficult tasks in the computing industry is the creation of reusable software components. The servlet, JSP, and EJB technologies are all steps in the right direction because they allow creation of clearly defined interfaces, encapsulated state, and transactional and security requirements. The security requirements are defined within the deployment descriptors for each specific component. Well-architected software creates components that can be reused across an enterprise or even used within multiple enterprises. These components communicate via the defined interfaces. The containers in which the components run act as mediators that manage access to the resources they encapsulate, such as database records, and manage the transactional state. The protocols used include HTTP, SOAP, and Java Remote Method Invocation (RMI) over the Internet Inter-Object Request Broker (ORB) Protocol (IIOP) (RMI-IIOP). These protocols allow the container to mediate the communication between the client and the server. The client includes the traditional desktop client, servers located in the same or another enterprise, and handheld devices. Figure 1.5 shows a few ways in which J2EE software components can be combined to create complex applications. Many other combinations, including connection to other services, are possible.

Figure 1.5. Composing Software Components to Create Applications

Separation of components and their mediation by a container suggests a model in which the security policies can be declarative rather than hard-coded within the applications themselves . In fact, this is the preferred approach because it is difficult, if not impossible , to change corporate security policies once they are written into applications.

The software life cycle takes an application from design and development through to maintenance. After a while, the developers and the maintainers move on to new projects or leave the company. People's lack of familiarity with the application leads to an environment in which there is increasing reluctance to modify functioning software, out of a fear of making changes that result in its failure. When security policies are embedded within the logic of the application, they tend to ossify, becoming rigid and inflexible . It is necessary to break this cycle by extricating the security policy from the application and making it the responsibility of the container and deployer of the application. The use of declarative security is discussed in the context of J2EE (see page 90).

1.2.3 Secure Communication in an Enterprise

One aspect of secure communication in an enterprise is confidentiality: protecting the contents of a communication session from eavesdroppers. The industry-standard protocol for such communication is SSL, which encrypts message content via a combination of public- and private-key encryption. Java technology supports SSL via JSSE, which is a framework and API for using SSL from within Java programs. As with many aspects of the J2EE and J2SE architectures, JSSE is designed so that any vendor's implementation can be installed and used without having to recompile the application, thereby enabling the desirable feature of vendor-neutral applications.

JSSE also supports both server and client authentication and data integrity. The authentication aspect of SSL allows the server and the client to be authenticated by using their private keys to digitally sign documents; the other party can authenticate via the use of public-key cryptography. Also, data integrity is supported so that it is possible to ascertain whether someone tampered with the message contents. JSSE is discussed in Section 13.4.1 on page 460.

In the enterprise realm, communication solely via SSL may be insufficient. Because enterprise applications are often transactional, transactional state needs to be communicated between applications. Some applications require that security information, including principal information for delegation, be transmitted between systems. One of the most common distributed communication models that supports complex enterprise applications is the Object Management Group (OMG) Common Object Request Broker Architecture (CORBA). Within Java, the OMG CORBA model is supported via RMI-IIOP. This protocol can be carried over SSL communication between processes to ensure confidentiality, in addition to the transport of transaction and security information.

SSL provides security between two end points. If messages are sent over message queues and enterprises need end-to-end security, SSL may not satisfy those requirements. In those cases, it is possible to achieve message protection and to carry security information within a message itself and remain independent of the underlying protocol. For example, a SOAP message can be encrypted and digitally signed, while carrying principal information in the message itself.