J2EE Platform

The Java 2 Platform, Enterprise Edition (J2EE) has emerged as a desired bleeding-edge technology that can provide the necessary infrastructure for developing distributed multitier applications. The J2EE framework is based on well-defined component models that conform to specific guidelines, are deployable in multiple server environments and, above all, can be reused to increase productivity. The J2EE platform defines the standards to server vendors and application developers alike for providing scalable, portable, secure, and reliable applications. These are the core factors in application development for enterprises that enable them to stay ahead of the competition.

Tiered Architecture Support

The J2EE platform is designed to address requirements in all the tiers, as described in Figure 5.1. The J2EE architecture defines the necessary protocols and standard API for developing and integrating the components that make up each of the tiers. Let's look at how J2EE addresses each tier's requirements and what components and services it provides for simplifying their development.

Client Tier

Most enterprise applications have to render the business function through multiple channels. The output rendered differs based on the client type; for example, an HTML page for Web browsers. HTML pages are normally generated dynamically using the JavaServer Pages (JSP) and servlet technologies. Web clients interact with the middle tier server using the HTTP protocol. XML is another common format in which the client and server interact.

Standalone clients written in Java or any other language can integrate with the middle tier server by using a standard socket library and implementing the connection protocol depending on the component being used; that is, HTTP for accessing servlets and JSPs, and RMI/RMI-IIOP for accessing Enterprise JavaBeans. The latest addition to the Java 2 platform—J2ME (Java 2 Platform, Micro Edition)—extends the middle tier services to other client models such as mobile devices, PDAs, and so forth.

Middle Tier

This tier represents the business logic components that take care of implementing the business function. One of the common components used to implement business logic is the Enterprise JavaBeans technology. EJB technology enables a developer to concentrate on the business logic and leave primary services such as life cycle management, naming, and transactions to the runtime environment, which holds the EJBs. The runtime environment is known as the container. The middle tier provides other services, such as messaging services using Java Messaging Service (JMS), naming services using the Java Naming and Directory Interface (JNDI), database connectivity using the JDBC (Java Database Connectivity) API, and much more.

Backend Tier

The components and applications that constitute the backend tier are critical to every enterprise business application because in most cases they represent the corporate data or legacy application or an enterprise information system. These components and applications form the backbone of the enterprise business. The J2EE platform provides the enabling technologies (that is, Java Connector Architecture [J2EE-CA]) for integrating existing enterprise legacy applications with the middle tier as described earlier. The JDBC API coupled with application server–specific connection pools provides an excellent infrastructure for database connectivity.

We've briefly gone through the different tiers that make up an n-tier application and the responsibilities associated with them. It's evident from the discussion that the middle tier has to be robust and extensible to successfully manage the business it models. Changing business needs have to be addressed almost immediately and without affecting the quality of service. The J2EE platform and the architecture it supports (with the help of the different components and services they offer) make the enterprise application development much easier. Let's now look at some key features of the J2EE platform in the next section. Let's also examine how WebLogic Server, built on the J2EE platform, provides a robust platform for implementing portable, distributed, n-tier enterprise applications.

Component Model Architecture

The cornerstone of the J2EE platform is the simplified architecture focused on a component-based development model. Some of the benefits it offers directly affect delivery time, which is one of the major concerns for large organizations deploying enterprise applications. The component model enables parallel development of the different components that make up the application. Figure 5.2 zooms in on the middle tier described in Figure 5.1 and illustrates the services and components supported by a fully compliant J2EE application server such as WebLogic Server. Most of the components and services described in Figure 5.2 are essential components in conforming to the J2EE platform specifications. Some of the services might be proprietary and this gives the application server vendor the ability to add value to its product. Almost all commercially available J2EE-compliant application servers, including WebLogic Server, stay on top of the current version of the specifications. This enables them to provide their customer/business with the maximum value that can be leveraged from the J2EE platform.

As you can see in Figure 5.2, there are multiple containers within the J2EE environment. These containers are runtime environments for different components of the platform. For example, Web applications are managed in a different runtime environment within the server (Web container) from that of the business domain environment like the EJBs (EJB container). This enables Web developers to create HTML/JSP templates, which can be used by application designers to incorporate the application behavior. In parallel, functional experts in collaboration with component developers (such as EJB developers) can create the business logic components. An application assembler can assemble all the application components that can then can be bundled with the configuration files and deployed by a deployer. Assembling an application is also done using standardized file formats (for example, *.jar, *.war, and *.ear files), depending on the application component. The deployment-time behaviors of the application are controlled by a set of deployment descriptors and configuration files. After the application is deployed, it can be managed by a maintenance team. Figure 5.3 illustrates the different parties involved in a component-based development model using WebLogic Server.

The J2EE specifications provide guidelines for the roles that a developer or set of developers may perform, including the ones specified in Figure 5.3 (that is, application component developer, assembler, deployer, and so forth). There are no hard-and-fast rules as to who should perform each of the functions. This is a logical demarcation because development teams might assign multiple roles to a developer. In very large-scale projects, it's possible that these roles could be split up into more specific functional areas, such as user interface designers, business data mappers, application logic developers, and so on.

Infrastructure and Services

The component model architecture addresses some of the main requirements leading to the development and deployment of enterprise systems in current technology scenarios. With Internet delivery time as a major requirement, most systems don't have time to concentrate on the development of auxiliary services such as security and making the system highly available. They depend on the application server vendors to provide the necessary infrastructure for these services and allow the enterprise systems the capability to configure them according to their business needs. We'll now look at some of the important infrastructure components and services that are part of the J2EE platform and that help in simplifying the design and development of enterprise systems.

Integration Services

As you saw in Figure 5.2, the J2EE platform provides the necessary infrastructure and well-defined APIs for integrating to existing enterprise applications and to external services such as directory services. Table 5.1 lists the different J2EE standard/framework services along with their uses in the J2EE-based enterprise development model.

Table 5.1. J2EE Platform Integration Services

J2EE Standard/Framework	Description
J2EE Connector Architecture (J2EE-CA)	Provides a portable framework for integrating applications such as ERP, CRM, and mainframe applications
Java Naming and Directory Interface (JNDI)	API for accessing enterprise naming and directory services
Java Database Connectivity (JDBC)	API set for accessing relational databases
Java Messaging Service (JMS)	Enterprise messaging infrastructure with a rich set of APIs for implementing standard, portable messaging applications, and asynchronous request-response model applications
Java Transaction (JTA)	API set for implementing transactional systems
XML API (JAXP)	Java API for XML provides support for XML-based application framework such as XML Web services
JavaMail	API set for sending and receiving mails
JavaIDL	Provides support for integrating CORBA services

Scalability and High Availability

Most J2EE application servers support clustering of services, which provides simplified distributed application scalability with absolutely no special code. An applications server cluster (for example, a WebLogic Server cluster) contains two or more instances of the application server providing the same kind of services to all clients. This provides increased scalability and high availability. All server instances in the cluster are equal and are transparent to the client making the request. The server instances can be distributed across different machines or in one big powerful machine. The cluster capacity can be increased easily just by adding new servers. These servers can be hosted on new machines or on the machines that are already part of the cluster.

The clusters are designed to address scalability requirements of the different services that are offered by the server; that is, transactions and resource management services such as connection pooling. These services impact performance and are the best candidates for clustering. The benefits of application server clustering can be summarized in two categories:

• Scalability— As the number of servers in a cluster increases, it directly affects the application's capacity positively. Additionally, new server instances can be added to a cluster without bringing down the application server environment, so there's no interruption of service for the end users.

  There's an auxiliary benefit to this because the application server automatically takes care of load balancing in response to fluctuating demand. For example, WebLogic Server provides the capability to specify an algorithm for load balancing that can be used to spread the client requests based on many factors such as machine's available memory, clock speed, and so on.

• High availability— Because deployed components run in multiple instances of the server grouped in a WebLogic Server cluster, a single server instance failure does not cause a request to fail. Request processing can continue with the help of another server instance. WebLogic Server automatically takes care of migrating the request to the server instance designated as the backup for the server that went down.

Security Framework

One of the key concerns for any enterprise architect is how to secure an application. The J2EE security framework eases this concern by the simple unified security model, which is adapted well by WebLogic Server. The granularity of the security framework provided as part of the J2EE platform is at the component method level. Component developers have the option to specify who should be able to execute a particular component method. The most common security mechanism is the role-based security mechanism in which users with the same privileges are grouped together. This is entirely configurable, enabling component developers not to worry about securing applications through code. But technologies such as Enterprise JavaBeans and servlets also provide APIs for programmatic security. All this provides for both greater flexibility and sophisticated security control for all the parties involved in the J2EE enterprise application development.

WebLogic Server and J2EE

WebLogic Server is built on the J2EE platform, thereby making it a robust platform for implementing portable, distributed, n-tier enterprise applications. WebLogic Server provides all the services for the J2EE components advocated by the specifications. The specifications are developed by the Java community, which includes many software vendors such as Sun Microsystems and BEA Systems.

Being an application server, WebLogic Server provides a perfect environment for implementing the middle tier described in Figure 5.1. WebLogic Server provides all services relating to Web clients, container services for business logic components implemented in EJB, JMS, and so on, and efficient resource management using connection pooling mechanisms. WebLogic Server leverages the component model very well. WebLogic Server also provides a proprietary application framework for seamless integration of WebLogic Server applications with BEA Tuxedo/CORBA services using WebLogic to Tuxedo Connecter (WTC). This is in addition to the Jolt API that also gives access to remote Tuxedo applications.

Development Aids—Tools and Components

WebLogic Server is bundled with its own set of tools that help develop, configure, deploy, and maintain applications. These tools are a mixture of GUI-based tools (such as the WebLogic Console and WebLogic Builder) and command-line based tools (such as EJBGen). WebLogic Console is used for managing the WebLogic Server environment. WebLogic Builder is used for building enterprise applications. EJBGen is used for generating the necessary component classes based on the business methods defined in the user-written Enterprise Java Beans.

The J2EE standard created a marketplace for development tools for different phases of the enterprise application developed on the J2EE platform. These third-party tools can be used during development, packaging, and configuration of Web applications and EJBs. Most of the tools are compatible with all J2EE application servers. WebLogic Server is part of the J2EE family so, of course, these tools can be used with WebLogic Server as well.

Apart from the tools, component-based architecture and design has enabled third parties to develop standard, reusable components using J2EE technologies such as servlets, JSPs, and EJBs that can be deployed in a J2EE-compliant application server such as WebLogic Server with no or little modifications. This eases the task of enterprises that are under constant pressure to roll out new functions as part of enterprise applications just to be part of the competition. For example, a component such as shopping cart can be used in wide a range of applications: an online bookstore and a grocery store, to name just two examples. Buying that component instead of developing it can save precious time.

Other Considerations

WebLogic Server has built on the J2EE security standard with additional features such as the Security Service Provider Interfaces (SSPI) for authentication, authorization, and role and credential mapping as well as auditing purposes. WebLogic Server allows third parties to develop security modules that can integrate seamlessly into the WebLogic runtime environment. Additionally, third-party administration tools can be integrated with the WebLogic Administration Console.

WebLogic Server clustering fully echoes the scalability and failover attributes that were explained earlier. Clustering is not mandatory for all J2EE components according to specifications. Not all components can be clustered in the current release of WebLogic Server. Table 5.2 lists the objects that can be clustered and provides information that's replicated among the servers in the cluster.

Table 5.2. WebLogic Server Clusterable Components

Component Type	Clustering Type
Servlets and JSPs	Maintains HTTP session states in memory, a file system, or a database.
EJB and RMI objects	Replica-aware stubs that can locate the bean instance anywhere in the cluster.
JDBC	Datasources, connection pools are clusterable and these objects should exist in all server instances.
JMS	JMS destinations are clusterable.
JNDI	Some cluster support (for example, RMI stubs and replicated trees).

WebLogic Server now provides improved availability for nonclustered services. An administrator can migrate a nonclustered service from one server instance to another server instance in the same cluster. This can be used when the server instance fails or for a scheduled maintenance.

So far, we've looked at the J2EE platform benefits and how WebLogic Server provides an effective J2EE-based enterprise solution. Now we move on to applying these concepts in architecting an enterprise application.

Architecting a J2EE Application

We've just scratched the surface of the J2EE and WebLogic Server platform and the benefits it offers when used to implement a large-scale enterprise application. We briefly covered some of the components (that is, EJB, servlets, JSP, and JMS) that were shown as part of Figure 5.2. But some of the most important constituents of the J2EE environment are the different containers that provide the runtime environment for specific components. For example, the Web container manages the Web application environment that contains the servlet and JSP components, and the EJB container provides the runtime environment for Enterprise JavaBeans.

Not all components are necessary for architecting a business solution. The programming model is flexible enough to support multiple channels of delivery as shown in Figure 5.1. For instance, certain client types don't require Web containers and the associated components, and some other clients might not require an EJB container and the beans deployed in it. The J2EE environment does not enforce the use of certain components in all application designs. This opens up a wide range of options when designing an application on WebLogic Server. Let's look at some architectures using some real-life examples.

Web Application Scenario

Consider the case of XYZ Pizza Company, which specializes in pizza delivery and is building a Web site to enable customers to order pizza online. The business function is limited to constructing your favorite pizza by specifying the type of crust (thick or thin) and adding the toppings and sides required. The customer has to specify the delivery address along with payment method, such as a credit card. Figure 5.4 gives a possible architecture for designing a Web site for the XYZ Pizza Company.

The servlets and JSPs listed inside the Web container might be the only functions for a fully functional online pizza ordering system. The servlets perform the dual functions of both the presentation layer and the business logic layer (which is bad practice). The database connectivity can be managed using JDBC, and integration with the credit card system can be achieved with either the help of a proprietary solution or a more portable Java connector architecture.

N-Tier Scenario

The Web application scenario explained in the preceding section will not work for more complex scenarios, which might involve multiple client types and many more business functions. Consider a banking system trying to extend all of its services (that is, account management, loans, and so forth) through multiple channels. Some of the common channels are an online system, an automated call center powered by an interactive voice response system, and a customer service department powered by customer-relationship management application (CRM). This is in addition to traditional branches with their own teller-system applications. In this business case, the business services offered are more complex than the XYZ Pizza Company.

The banking application architecture is driven by many factors apart from the number of services that are offered as part of the application. Let's look at some of them:

• Multiple client types such as IVR, Web, and so on that understand different protocols.

• Rapid application design leveraging off-the shelf business logic components. As you can see, some of the entities involved in the business case—including customer, account, products the bank offers—are common across many other horizontal businesses and might be available as ready-made components.

• Modular development to enable multiple teams to work on different aspects of the application. The most evident is splitting the presentation and business logic components so that Web designers and domain experts can work simultaneously.

• Enterprise information system integration and the options available for integrating the new application with the existing corporate data and legacy systems. The options may be custom built or well-defined products that can be integrated seamlessly with the new application.

Keeping in view of the some of these requirements, a bird's eye view of the application architecture for the banking system is illustrated in Figure 5.5.

The other consideration during the design of complex enterprise applications in WebLogic Server is the use of XML for data transformation. Java and XML are complementary technologies. Java's popularity is driven by the Write Once, Run Everywhere concept, and in a similar fashion, XML provides portability for data. It isn't the most important choice for data exchange and doesn't necessarily impact the overall architecture. But the data portability definitely simplifies data transformation, especially when dealing with heterogeneous rendering depending on the client types. For example, the XML data messages between the different client types and their server components make it easy to integrate the different channels with one enterprise application sharing the business logic components. In fact, the use of XML is not limited to this, but can be used anywhere in the application; namely, between the server components in the middle tier.

Global Auctions—Case Study

Now let's look at a global auctions system in the light of the N-tier scenario we discussed earlier. The Global Auctions Management Systems may involve interactions with external systems, such as a credit card company, an accounting system, and the global auctions database that stores the users (buyer and seller) and their interactions. Figure 5.6 illustrates the architecture for the global auctions system along with some of the components involved in the interactions between the different users—guests, sellers, and buyers.

So far, we've gone through what is needed for an n-tier application and how J2EE helps solve these business problems in an effective manner. We've also gone over how to architect some of the common business problems. In getting an enterprise application to work as relates to the needs of the business, there must be coordination between the different communities that make up the enterprise application team. This coordination can be achieved if all of the communities can speak in a common language. But the skill sets don't necessarily match, which makes things difficult for effective communication. For instance, the user community, with its expertise in the functional knowledge of the business, is responsible for providing the application inputs—in other words, what they want from the enterprise application. The application designers are responsible for translating those requirements into meaningful representation that can be understood and reviewed by the user community. After making sure that the application design truly reflects the users' requirements, the architects have to come up with a viable technical solution. They're responsible for coming up with a high-level design strategy and choosing the different J2EE components that match the technical solution. Finally, the identified components must be represented in a way so that they can be communicated to the developers. The level of communication and disparate skill sets make it difficult to implement an enterprise application.

We'll now look at how we can address these problems effectively with the help of some strategies and techniques that have evolved over the years. We'll also look at a modeling technique, the MVC pattern, and two of the most-adopted development strategies available.