Chapter 1. Understanding the Java 2 Platform, Enterprise Edition

Overview

One of the challenges that people encounter when being introduced to something new is deciphering exactly what they are learning, and what the constituents of that subject are. Only once they have a good basic comprehension of these questions can they really begin the learning process.

The Java 2 Platform, Enterprise Edition (J2EE) is no exception to this rule. There have been many cases where people have strayed away from using this platform for developing business applications, purely on the basis they could not understand it or it was presented as a very complex specification. Therefore it appeared to present a high degree of risk in its adoption for any development effort.

The objective of this chapter is to cut through the complexities of the J2EE specification, presenting it in a very intuitive manner. Subsequent chapters in Part I of this book will methodically build your knowledge of the J2EE platform.

Java Technology Today

Today, Java is more than just a programming language; it has become a technology and a platform for developing applications for the Internet and enterprise information systems, as well as electronic consumer devices.

In order to promote the use of the Java 2 Platform across a wide spectrum of application scenarios and environments, Sun provides three editions of the Java 2 technology:

  • Micro Edition (J2ME technology) enables a wide range of consumer devices (such as PDAs, pagers, and cell phones) to leverage the Java technology without a large resource requirement.

  • Standard Edition (J2SE technology) is a suite of foundation Java classes for developing and deploying client-server software solutions.

  • Enterprise Edition (J2EE technology) extends the Java 2 Platform, Standard Edition to support the development and deployment of modular and reusable server-side business logic through the use of the Servlets API, JavaServer Pages (JSP), Enterprise JavaBeans (EJB), and XML.

Java technologies support hardware and OS independence by enabling system services to be accessed directly through the Java 2 Platform APIs within the context of a standards-based Java Virtual Machine (JVM), as opposed to the complex APIs of an underlying device (PDAs and cellular phones) or operating system (Solaris, Linux, Macintosh, and Windows).

There is a theory that “consistency builds competency.” The Java 2 platform promotes a consistent and proven mechanism for constructing applications independent of the deployment environment. This “Write Once and Deploy Anywhere” approach permits developers to focus on developing skills and best practices related to the construction of business applications using one programming language, Java, regardless of the operating system or hardware the application will be hosted on. Organizations that take a consistent approach to developing applications can gain a huge return on investment from their technical staff just by ensuring their developers have focus in developing and practicing their technical skills.

Note

“Write Once, Run Anywhere” is a promise that is exclusive to the Java language. As long as a device or an operating system can support a Java Virtual Machine (JVM), which interprets the Java compiled code known as Java bytecode to computer machine or device instructions, Java software will run on it.

Today the evolution of the Java 2 Platform has moved away from Sun and is fostered by the Java Community Process (JCP), an international organization of Java developers and stakeholders of the Java technology. The objectives of the JCP Executive Committees are to ensure that the revisions to the Java technology specifications, reference implementations, and compatibility test kits meet the vision of the world-wide Java community in a standard and disciplined manner.

Note

You can find more information on the Java Community Process and how you can participate in the evolution the Java 2 Platform by visiting www.jcp.org.

The Challenges of Today’s eSystems

Undoubtedly, a high percentage of applications are being developed for the Internet using multiple technologies and platforms. However, is just building for the Internet the main challenge an organization faces?

Organizations recognize the benefits the Internet brings to application deployment in terms of cost, productivity, and user reach. They are also aware that Internet-based business solutions need to adhere to a proven distributed and n-tier architecture, as illustrated in Figure 1.1, where

A distributed application architecture is organized into several tiers.

Figure 1.1. A distributed application architecture is organized into several tiers.

  • An Internet browser serves as the client or front end to an application.

  • Middle tiers serve as the presentation and business logic domains, protecting the client tier from its complexities, and implementing the services required to integrate existing enterprise information systems (EIS).

  • An Enterprise Information Management System tier supports the data repositories, such as relational database management systems, document management systems, and other legacy systems (Enterprise Information Systems [EIS]) required to present or store application data or information.

However, developing Internet-based distributed information systems is a mammoth shift for most organizations. Organizations can become convinced that through the use of Internet technologies they will automatically become more tactical and strategic by having data, information and knowledge more accessible. But, where there are benefits, there are always risks, and sometimes these risks can be the Achilles’ heel an organization had never wished for.

In order to prepare for eSystems, organizations must address and resolve technical challenges that are tightly coupled with Internet-based technologies; for example

  • The technologies employed to form the Internet platform within an organization must outlive their derived business solutions to ensure there is return on investment from technology reuse.

  • The technologies must embrace a robust security architecture that can interoperate with security product vendors, which can technically and operationally bring to reality a single sign-on solution.

  • The presentation, business logic, and data aspects of business solutions must be kept separate to allow the applications to evolve and be managed easily.

  • The deployment of business logic must be managed and adaptable, according to an organization’s changing business climate and needs (time-to-market and time-to-share).

  • Distributed and scalable architectures must be possible, to support the current, target, and potential user traffic schemas.

  • The deployed applications must have “heart-beat” mechanisms so they can be monitored.

  • High availability with aggressive fail-over mechanisms must be part of the total solution for mission-critical business systems.

Another aspect of the introduction of eSystems that needs to be addressed is the consequences of using the Internet as a de facto medium for deploying business solutions; for example:

  • Will there be a need to integrate legacy applications?

  • Is there a need to support a heterogeneous computing environment?

  • What methodologies will be required to develop the eSystems?

  • Do you have the in-house skills to develop eSystems through a full systems development lifecycle?

  • Do you want to avoid vendor lock-in for any of the technologies and platforms adopted?

  • Will the eSystems development efforts follow standards?

  • Will there be cultural issues that need to be addressed to move to a new business application paradigm?

For an organization to be successful in its e-strategy for either developing business applications or retrofitting legacy applications for the Internet, the previous touchpoints do need to be addressed, and a resolution placed into motion.

You will rapidly discover, both in this chapter and the rest of this book, that there are two keys aspects for a successful eSystem. The first is a standards-based approach to the construction of your application, which can easily be resolved through the adoption of the J2EE specification. The second is the need to implement a robust application infrastructure solution that can support J2EE applications and their associated security and the administration requirements in a scalable, platform-independent, and cost effective manner, which can be resolved through the use of the WebLogic Platform 7.0.

To learn how to derive your Application Infrastructure requirements and the WebLogic Platform, see Chapter 8.

However, there is one caveat to the previous statement—J2EE and the WebLogic Internet platform can only address the technology-centric challenges. Organizational challenges such as the cultural acceptance, adoption of new methodologies, and training for the new paradigm of developing business applications need to be addressed immediately before veering into the Java 2 Platform.

As you will realize in the following sections of this chapter, J2EE is only a specification on how to use the Java 2 Platform for software development. It does not provide you with a business solution tailored for an organization’s needs or the organizational changes required for its adoption to be totally successful—that is the mission of Part I of this book.

The Java 2 Platform, Enterprise Edition

J2EE is a platform specification and branding initiative undertaken by Sun to provide a unified framework for developing and deploying component-based, server-centric, and multi-tier enterprise applications. Even though its specification is in constant and disciplined evolution through the Java Community Process, its mission is to support the ever-increasing complexities of today’s and tomorrow’s rigorous business application requirements. J2EE was officially released in late 1999, and it is still undergoing changes with each new release. The current release of J2EE is 1.3.

J2EE derives its benefits through a standards-based and proven architecture approach that is defined from the following elements of its specification:

  • J2EE Platform—A standard platform for hosting J2EE applications, which is specified as a set of required Java Technology Components and Service APIs.

  • J2EE Application Programming Model—A standard programming model for developing multi-tier applications.

  • J2EE Compatibility Test Suite—A suite of more than 15,000 demanding compatibility tests for validating the J2EE compliance of J2EE product providers, such as application development tools and application servers.

  • J2EE Reference Implementation—A reference implementation of the J2EE platform for demonstrating its capabilities and proofing its operational definitions.

Caution

J2EE is sometimes interpreted as being a specification as well as an application that can be leveraged to build robust and scalable server-centric business applications using the Java language. This is a misconception; J2EE is purely a specification. However, J2EE can be downloaded from the Sun Web site with the infamous Pet Store example, which showcases best practices on how to use the technology toward an e-commerce application.

The following sections provide an overview of the elements of the J2EE specification that were discussed in this section. You will learn the benefits of the J2EE Platform and how you can derive a scalable, interoperable, and robust application from its specification elements.

The J2EE Platform—Technology Component and Service APIs

If you are new to the J2EE platform, at the top of your agenda should be an easy comprehension of what it is. As stated earlier in this chapter, the J2EE Platform is a specification. You can also view it as a philosophy for developing scalable, robust, and interoperable business applications through the employment of Java Technology Components and Service APIs. What it is not is a shrink-wrapped application that you can use or customize immediately.

In order to understand the J2EE platform, you do need to understand the definitions of the following terms and review how they relate to each other as shown in Figure 1.2.

You should understand the technology components and service APIs that constitute the J2EE platform.

Figure 1.2. You should understand the technology components and service APIs that constitute the J2EE platform.

  • Java Technology Component APIs—Through the employment of the J2EE technology components, eSystems are developed as a suite of loosely coupled distributed components, which exist and are managed in the context of containers within a Java Web or J2EE Application Server. These containers provide deployment and runtime support for Java client applications, Web components (servlets and Java Server Pages), and server components (EJBs). They also provide a federated view of the services provided by the underlying application server for these components.

  • Java Service APIs—eSystems will always require one or more server-side services. The role of the J2EE Service APIs is to provide a common programming interface layer on top of multi-vendor, heterogeneous infrastructure services such as security, transaction management, messaging, email, and database access. Through this level of abstraction, the development team can focus on developing the core business functionality instead of building the infrastructure for that functionality. The following sections describe the Java technology component and service APIs that a J2EE 1.3 platform must support.

Java Servlet Technology 2.3

Java Servlets are platform-independent Java classes that are compiled to platform-neutral bytecode which can be loaded dynamically into and run by Java-enabled Web servers. They are regarded as Web Components, because their role is to generate dynamic content to Web clients via a request/response paradigm implemented by a Web container.

Servlets are similar to CGI but much easier to write, since servlets use Java classes and streams. They are also faster to execute because servlets are compiled to Java bytecode, and at runtime the servlet instance is kept in memory.

JavaServer Pages Technology 1.2

JavaServer Pages are considered Web components because their role is to generate dynamic content for Web-based applications. A JavaServer page is a text-based, presentation-oriented mechanism to develop servlets, as they also define how to process an incoming client request as well as generate a dynamic response. Like Servlets, JavaServer pages exist in the context of a Web container. They are compiled into Servlets by a J2EE-compliant application server, such as WebLogic Server, and hence are treated the same as Servlets at runtime.

To enable this operation, a JavaServer page is composed of static template data such as HTML, DHTML, XHTML, and XML. When combined with a JavaBeans class and tag libraries, JavaServer pages give you an easy way to keep content and display logic separate. The advantage of separating content and display logic allows content, graphics specialists, and Java developers to focus on their domains of expertise without having to be proficient in both content presentation and presentation logic.

Enterprise JavaBeans Technology 2.0

The J2EE specifications define a model for developing and deploying server-side Java components, and are therefore considered Server components. Enterprise JavaBeans (EJBs) are the foundation of the J2EE platform for addressing multi-tiered and distributed application architectures. The role of EJB components is to encapsulate business logic. There are three types of EJBs:

  • Session beans—Model coarse grained business services. There are two types of session beans: stateless and stateful. For stateless session beans, once the client communication ceases, the session beans are recycled back to the ready pool and prepared to serve new client requests. For example, “calculate product price” can be modeled as a stateless session bean. Stateless session beans do not maintain state between different client requests. On the contrary, stateful session beans model the interactions with the clients, hence maintaining the state for their corresponding client. For example, a Travel Agent client request can be modeled as a stateful session bean.

  • Entity beans—Enable persistent data communication with a client and a database. If the client terminates or if the server shuts down, the J2EE application server will ensure that the entity bean data is safely captured for recovery at a later point in time.

  • Message-driven beans—Enable asynchronous communication sessions with the Java Message Service (JMS) listener to allow for application interoperability and scalability.

EJBs exist and execute within an EJB container in the context of a J2EE-compliant application server, such as BEA WebLogic Server 7.0. It is the role of the J2EE application server to provide a scalable, high-performance, and stable runtime environment for EJB components, as well as manage and recycle the resources required by EJBs during their execution, such as security, memory, CPU utilization, network sessions, database sessions, and threads. For this reason, the application developer does not have to worry about coding for infrastructure services such as database access, transaction support, security, caching, and concurrency.

Tip

Since EJBs are the most resource-intensive technology that implement business logic in the J2EE specification, you will need a high-end application server that implements an efficient resource recycling mechanism in the EJB container, such as the WebLogic Server 7.0.

JDBC 2.0 API

The JDBC specification is essentially a bridge to invoke SQL commands from the Java programming language methods to a relational database management system (RDBMS). For example, you can use the JDBC API to access a RDBMS from a Servlet, JavaServer page, Session bean and Entity bean.

JDBC is modeled on the Open Database Connectivity (ODBC) specification and is therefore fairly simple and well established. Just like ODBC drivers, JDBC accomplishes database connections by using a driver mechanism that translates JDBC calls to native database calls. The JDBC API is composed of two parts: an application-level interface used by J2EE components to access a database, and a service provider interface to attach a JDBC driver to the J2EE platform.

There are four types of JDBC drivers that you can use:

  1. Type 1 is a JDBC-ODBC bridge, which comes with the J2EE Java Development Kit (JDK). The ODBC driver is required to be installed on the connecting client machine.

  2. Type 2 drivers convert the JDBC calls that a client application invokes into the native calls of a native driver currently installed on the client machine. Hence, this type of JDBC driver requires the native database driver from the database vendor to be installed on the client machine as well.

  3. Type 3 drivers make no use of native drivers on the client machine and hence are portable across platforms that support a Java Virtual Machine, enabling all communications with an RDBMS to be channeled thorough it.

  4. Type 4 drivers are written in 100% pure Java and communicate directly with an RDBMS using proprietary network protocols. Unlike Type 1 and Type 2 drivers, Type 4 drivers do not require any pre-configuration of the client machines.

For these reasons, it is important that you select the appropriate JDBC driver suited for your application environment.

Java Message Service 1.0

The JMS API is the J2EE messaging standard that supports the asynchronous exchange of messages between J2EE components. The distributed communication between J2EE components is loosely coupled, since sender and receiver components do not need to be aware of each other and hence can operate independently.

The JMS API supports two messaging models:

  • Point to point, which is based on message queues. In this model, a message producer sends a message to a specific queue. A message consumer can attach itself to a queue to listen for its incoming messages. When a message arrives on the queue, the consumer takes it off and responds to it. However, message consumers do have the capability to filter messages to specify the exact message types they are waiting for.

  • Publish and subscribe is a model where message producers send messages to a topic queue. All registered message consumers for that topic queue are then able to retrieve these messages.

Java Transaction API 1.0

The Java Transaction API (JTA) forms the basis of managing the transaction-consistency and integrity of distributed transactions, primarily on behalf of JMS, EJBs and JDBC 2.0. JTA is a high-level API that consists of two parts:

  1. A Transaction Interface that enables transaction demarcation. This allows transactions derived from distributed components to be bound by a global transaction. This is purely a means of creating one logical unit of work from groups of transactions.

  2. XA Resource Interface is based upon the X/Open/XA interface that enables the handling of distributed transactions requiring a Two Phase Commit.

Note

▸ To learn more about the JTA and the XA Standard, see “XA-Compliant Resources,” p. 539.

Typically, you will not need to be concerned about programming explicit transactions with JTA, since that work is done through the JDBC and EJB APIs handled by the container and configured by the application deployment descriptor.

JavaMail Technology 1.2

Email is an integral part of every corporate workplace, and when business applications have to reach the masses of an organization, you can be assured some form of integration with an email system will be required. The JavaMail API, in conjunction with a JavaMail service provider, allows email capabilities from the J2EE platform.

JavaBeans Activation Framework 1.0

The JavaBeans Activation Framework is a requirement to support the JavaMail API, since its services determine and perform operations on email messages.

J2EE Java Connector Architecture API 1.0

The Java Connector Architecture (JCA) is one of the first attempts by the Java Community Process to establish standards in the application integration arena, establishing an awaited addition to the J2EE set of specifications. JCA is focused on the design of adapter software used to connect J2EE applications to heterogeneous, non-Java information systems (EIS), legacy databases, and software packages, such as SAP R/3, CICS, PeopleSoft, JD Edwards, and Baan.

The connector architecture enables an EIS vendor to provide one standard resource adapter that can be plugged in to any J2EE application server that supports JCA. This resource adapter is basically a J2EE component that implements the JCA for a specific EIS, and is deployed to an application server as a Resource Adapter Archive (RAR file) or within the context of an Enterprise Application Archive (EAR file).

A resource adapter implements two types of contracts that enable access to its EIS from within the application server, as illustrated in Figure 1.3.

Access an EIS through a Resource Adapter and its Contracts.

Figure 1.3. Access an EIS through a Resource Adapter and its Contracts.

The Application Contract defines the API that enables J2EE application components (Servlets, JavaServer Pages, and EJBs) to access and transact with the EIS. Since the resource adapter exists in the context of an application server, services required to facilitate communication between the J2EE components and the EIS, such as transaction integrity, security, and connection pooling, are leveraged fully from the application server. To enable the use of these application server services, the JCA defines the following types of System-Level contracts:

  • The Transaction Management Contract enables the transaction managers within the application servers to communicate with the resource manager within the resource adapter to ensure transaction integrity.

  • The Connection Management Contract enables the application server to pool connections to the target EIS, hence providing a scalability solution to the number of connections requiring access to the EIS.

  • The Security Contract provides a secure mechanism for the J2EE components to access the EIS, as well as providing security to protect the EIS itself from unauthorized access to restricted information.

Note

The System-Level contract only exists between the application server and the resource adapter and is transparent to the J2EE components accessing the EIS.

Currently and for the short-term future, the resource adapter will be specific to its EIS, requiring J2EE application server vendors to collaborate with EIS vendors in the development of specific resource adapters to keep all system-level mechanisms—transactions, security, and connection management—transparent from the J2EE components. However, the objective is that one day the application adapters will become commodities like database drivers, allowing application integration vendors to focus on providing scalable and reliable integration solutions rather than locking customers into proprietary application adapters.

Note

The JCA 1.0 specification is a significant extension to J2EE, yet it falls short of meeting all the requirements of application integration projects. For this reason, J2EE integration with non-Java enterprise information management systems will continue to depend partially on proprietary solutions. The WebLogic Integration 2.0 product, which is part of the WebLogic Platform, does provide extensive support for integration with non-Java systems beyond the JCA 1.0 specification. To ensure a non-proprietary solution to integration requirements, BEA is playing a leading role in driving the new JCA 1.5 specification.

Java Naming and Directory Services API

The JNDI API is the standard Java API for naming and directory access. The role that JNDI plays in the J2EE architecture is in minimizing dependencies between clients and services.

Since the components of a J2EE application run separately and often in disparate environments, there needs to be a means for client and application server tier code to look up and reference other code and resources. Client and application code use the JNDI to look up user-defined objects, such as Enterprise Beans, and environment entries, such as the location of the JDBC DataSource objects for looking up resources in the data tier.

Tip

JNDI promotes location transparency of client services, and hence the ability to make server-side changes to those services without cascading those changes to any dependencies, such as EJBs, Servlets, and JavaServer Pages, using those services.

Java API for XML 1.1

eXtensible Markup Language (XML) is a meta language defined by the World Wide Web Consortium (W3C) for representing, through a set of rules, guidelines, and conventions, a text-based cross-platform data format. Through these standards, XML allows applications to transfer both page content and information on how the content is structured.

Note

XML is similar to HTML in that it uses tag and attribute constructs in its definition of the data in a file. However, HTML specifies the definition of each tag and attribute, as well as their presentation attributes in a browser. XML, on the other hand, only uses tags to structure the data and does not define any of the presentation semantics of that document. The structure of the data contained within an XML document is described in a Document Type Definition (DTD) or XML Schema. Applications that support XML can communicate and exchange data without any prior knowledge of each other, as long as they share or are capable of interpreting the DTD or the XML schema.

There is a very strong relationship between Java and XML to build interoperable and cross-platform applications. Java enables you to construct portable applications across multiple hardware platforms, while XML enables the data to be portable across many applications, regardless of their implementation technology.

To address the increasing use of XML as a mechanism to exchange and process data between applications, the Java API for XML Processing (JAXP) has been introduced into the J2EE specification to support Java applications that need to process XML data. The JAXP API enables Java-based applications and components to process and transform XML data completely independent of a particular XML parsing (processing) technique. For example, standards-based XML parsers such as the Simple API for XML Parsing (SAX), Document Object Model (DOM), and XML Stylesheet Language Transformations (XSLT) are all supported by the JAXP API. The advantages of such an approach allows you to have the flexibility to swap out or select the XML parsing technique that best meets your XML processing requirements without any modifications to the Java application code.

Note

▸ For detailed information on XML standards, please refer to the World Wide Web Consortium Web site (www.w3.org/XML).

For a detailed discussion on how XML data is processed within the context of the WebLogic Server 7.0, see Chapter 29.

Java Authentication and Authorization Service 1.0

JAAS extends the security architecture of the Java 2 Platform (Standard and Enterprise Edition) by providing the following easy-to-use mechanisms:

  • An authentication mechanism for users to determine who is currently executing the Java code without depending on the underlying authentication system. Through the use of JAAS, an authentication system can be swapped without any ramifications to the Java application code.

  • An authorization mechanism for users to ensure they have the access control rights required to do perform their operations, through an extension to the security policies that govern what access rights are granted to the executing code at runtime.

J2EE Application Programming Model

In today’s aggressive economy, organizations are slowly realizing the Time-To-Share paradigm where sharing data, information, and knowledge is imperative to succeed and gain that extra competitive edge. They are building complex business applications, which, perhaps not today but in the future, may need to communicate between each other in a transactional manner. It is also true that most business application development efforts are not all development, but also entail a high degree of integration plumbing work to interface legacy enterprise information systems (EIS) that are deemed as being important to the value of the business application. How is this going to be possible if the applications are built using different technologies and on multiple operating system platforms?

The solution is that organizations need to wake up to Java and the J2EE platform for developing all their enterprise server-centric applications. The J2EE Application Programming Model offers a component-based and multi-tiered approach to the design, development, assembly, and deployment of enterprise applications. This model not only reduces the application development cost, but also enables a fast track for the design, development, and deployment of application logic. The following sections will expand on the benefits of the J2EE Application Programming Model.

The Benefits of J2EE Components

J2EE components are pre-built pieces of Java application logic code that can be assembled with other components to form a complete J2EE application. J2EE components exist in the context of a container environment, which can be implemented on an application client, Web server, or Application server. The role of the container is to provide a runtime environment for the component, providing services required for its execution. J2EE application servers and containers will be discussed later in this chapter.

The J2EE Application Programming Model defines four types of J2EE components as follows:

  • Application clients are Java GUI programs that execute on a desktop computer and can fully interact with all the facilities of a J2EE Web or application server.

  • Applets are GUI components that can execute in a Web browser or a variety of other applications or devices that support the Applet container, which is composed of the applet programming model, the Java 2 Platform Standard Edition, and JNDI.

  • Web components exist in the context of a Web Container within a J2EE-compliant Web server. Web components are comprised of servlets, JavaServer Pages, Web filters, and Web event listeners.

  • Server Components exist in the context of an EJB Container within a J2EE-compliant application server. Enterprise JavaBeans are the only server components currently within the J2EE specification.

Many people confuse Java objects with J2EE components. Even though they may share the same language, they are constructed quite differently to promote reuse as follows:

  • Java objects offer reuse through inheritance.

  • J2EE components offer reuse through encapsulation.

Embracing J2EE component-based development offers the following benefits:

  • Higher productivity through the reuse of components, which are pre-built and pre-tested.

  • Rapid development, since components can be assembled very quickly and deployed to form an application.

  • Better testing methods, and hence high-quality deployed applications, since application developers can concentrate on testing their components before they are deployed for integration testing.

  • Easier maintenance, since components are relatively standalone pieces of Java code.

The J2EE specification relies upon the application server (WebLogic Server) to provide the required infrastructure support (security, transaction, persistency, high availability, and high scalability) allowing the developer to focus on the implementation of the business solution.

Multi-Tiered Architecture

The J2EE platform uses a multi-tiered distributed application model where

  • An application’s logic is divided into Web (servlets or JavaServer Pages) or Server (EJB) components, according to the functionality desired.

  • The residency of the application components depends on which tier in the multi-tiered J2EE environment the application component belongs in.

The tiers of a multi-tiered J2EE environment are defined as follows:

  1. Client Tier

    The client tier’s role is to present information and collect input from the end user through an interface display such as an Internet browser, PDA, or cellular phone displays. J2EE technology supports multiple client presentation technologies, including Hypertext Markup Language (HTML) clients, Java applets, Extensible Markup Language (XML) documents, and Java technology-based standalone clients.

    However, for simple interfaces and Internet applications, the Web browser is regarded as the Web client of choice, primarily because of its widespread adoption, inherent multi-platform support, and above all, a built-in Java virtual machine to run Java components.

  2. Web Tier

    This tier’s role is to accept user input from HTML, applet, and XML clients in order to generate the appropriate response to the J2EE client. The Web tier exists on a Java-compliant Web Server, and is implemented using servlet or JSP J2EE technology components.

  3. Business tier

    The role of the business tier is to implement presentation or business logic through the employment of Enterprise JavaBean (EJB) J2EE technology components. EJBs exist in the context of an EJB container, a runtime environment within J2EE-compliant application servers such as WebLogic Server 7.0. The role of the container environment is to manage the services the EJB may require: for example, security, state, and transaction management.

  4. Enterprise Information System (EIS) Tier

    The Web and Business tiers interact with other enterprise information systems such as databases, mainframes, or other legacy systems in order to Create, Read, Update, or Delete (CRUD) data or information. J2EE applications communicate to the systems that form the EIS tier through the JDBC, JNDI, JMS, and JavaIDL J2EE service APIs.

The J2EE application programming model depicts four distinct application tiers. In practice, however, you will find that most J2EE applications are implemented using a three-tiered model based on the locations of the J2EE application components since the Web and Business tiers are sometimes collectively referred to as the Application Server Tier, as illustrated in Figure 1.4.

The J2EE three-tier architecture.

Figure 1.4. The J2EE three-tier architecture.

J2EE Compatibility Test Suite

There are hundreds of J2EE product providers that produce Web and application servers, platform APIs, and development tools. The J2EE Compatibility Test Suite (CTS) helps J2EE product providers validate that their products meet the requirements of the J2EE platform specifications.

The J2EE Compatibility Test Suite is a standard set of more than 15,000 test cases derived from the J2EE specification requirements. The products that pass the CTS are considered J2EE compliant and may display the Java Compatibility Logo. The Java Compatibility Logo is an extremely useful aid for selecting J2EE products you may need in the application development process.

Note

For more information on the J2EE Compatibility Test Suite, please visit the SUN CTS Web site at http://java.sun.com/j2ee/compatibility.html.

J2EE Reference Implementation (RI)

The primary role of the J2EE RI is to demonstrate the operational definition of the J2EE platform by passing the J2EE CTS without any errors, hence proving the J2EE specifications can indeed be implemented.

For this reason, the J2EE RI is considered a controlled benchmark for

  • J2EE application developers to test the portability of their J2EE applications.

  • Application server vendors to test the implementation of their Web and EJB containers and J2EE service APIs.

J2EE Application Development Roles

The types of development roles that apply to most J2EE application development efforts can be easily derived from the J2EE architecture tiers that need to be employed. Using the standard multi-tiered J2EE Application Programming Model, the development of a majority of J2EE applications will require the following types of skills and roles, as illustrated in Figure 1.5.

J2EE development and deployment roles.

Figure 1.5. J2EE development and deployment roles.

Presentation Content Developers

One of the problems that most Internet application development efforts face today is that there is too much emphasis placed on the actual development of the business logic, and not enough on making its interface attractive and aesthetically useful. The result is a resistance to use the application, or just switching to another method as a means to achieve the same result. These brief, but disappointing, encounters can permanently affect the productivity and efficiency of an organization.

Organizations are now realizing that the actual usability (GUI aesthetics and ergonomics) aspects of an application are a key element of its success. At the same time, the quality of GUI interface demanded by the business application users and the sophistication of Web GUI development are reaching heights that most Java developers can comprehend, and they should be able to adequately educate themselves to provide any development value.

For this reason, organizations need to use specialists in art, ergonomics, mass media, and creative content who will collaborate with J2EE developers to design and implement the J2EE application interface.

Web Component Developers

The role of a Web component developer is to develop the presentation logic that is supporting a Web-based J2EE client interface within the framework of a J2EE-compliant Web server. Ideally, a Web component developer will need to be well versed with the development of JavaServer Pages, servlets, Web-based applets, and Web technologies such as HTML and XML.

Business Component Developers

The primary skill required for business component developers is the capability to map the business requirements into business logic, which is implemented on the J2EE platform as Enterprise JavaBeans. Ideally, they should be familiar with the business domain they are developing for, as well as possess technical knowledge of the J2EE platform architecture and how it can communicate with the EIS tier.

EIS Integrators

Sometimes a J2EE project requires a high degree of integration with multiple systems within the EIS tier which are not Java-based, or perhaps the technologies are rather proprietary in nature. In such scenarios, an EIS integration specialist will need to be involved in designing, developing, and implementing the communication pipeline between the J2EE platform and the specific enterprise information system.

J2EE Application Deployment Roles

The J2EE platform promotes a sequential and modular mechanism for the deployment of its applications. There are a series of steps, which are conducted by specific roles (also known as providers), in the deployment of J2EE applications, as depicted in Figure 1.5, and described as follows.

J2EE Product Provider

The J2EE product providers are companies, such BEA Systems, IBM, and Sun Microsystems, which implement the J2EE platform according to the J2EE Specification within their products (operating systems, database systems, application servers, or Web servers).

J2EE Tool Provider

A tool provider provides tools for the development, assembly, packaging, and deployment of J2EE components and applications. Such providers include BEA Systems, TogetherSoft, WebGain, and Borland.

Note

A product provider will in most cases provide tools for the deployment of applications into their application server environments. In such cases, they are also considered to be tool providers as well.

Application Component Provider

The application component provider is either a J2EE Web or business component developer who creates Web components, enterprise beans, applets, or application clients for use in J2EE applications. One of the goals of the J2EE Application Programming Model is to ensure that the infrastructure services required by J2EE components, such as security, database access, and transaction management, are not the focal point of the J2EE component developers, whose role is primarily to implement the business logic into J2EE components (servlets, JSPs, and EJBs).

J2EE achieves this by transferring these service responsibilities on to the J2EE platform, which provides a way to specify them through XML-based declarations that are stored within deployment descriptors (.xml files). These deployment descriptors are completely separate from the component code, and enable a J2EE application to be modified without having to modify any of its associated components.

The first step in the J2EE application deployment process is for the J2EE client, Web, and server component developers to package their components that will form the J2EE application into modules of similar component types:

  • Client components are all compiled, and the .class files with a deployment descriptor (application.xml file) are then packaged to form the Java Module (.JAR file).

  • Web components are all compiled, and the .class, .jsp, .html, and .gif files with a deployment descriptor (Web.xml file) are then packaged to form the Web Module (.WAR file).

  • Server components (EJBs) are all compiled, and the .class files with a deployment descriptor (ejb-jar.xml file) are then packaged to form the EJB Module (.JAR file).

Application Assembler

The application assembler’s role is to receive the application component modules (.JAR and .WAR files) from the component providers and assemble them into one Enterprise Archive (EAR) file.

Application Deployer

Through the use of tools provided by a product provider, the role of the application deployer is to deploy the J2EE application into the context of a J2EE-compliant application server, such as the BEA WebLogic Server 7.0. In order to deploy a J2EE application, the deployer will adhere to the following three-step deployment process:

  • Installation—The deployer moves the application components to the server machine, and generates the additional container-specific classes and interfaces that assist the containers in managing the application components at runtime.

  • Configuration—Validates and modifies the deployment descriptor of the J2EE application supplied by the application component providers, in order to resolve any external dependencies, implement security settings, and set any transaction attributes.

  • Execution—The deployer starts the J2EE application.

System Administrator

The role of the system administrator is to maintain and administer the J2EE application server environment once the J2EE application has been deployed. Ideally, the system administrator should be using tools certified by the product provider of the application server for any maintenance and monitoring operations.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset