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:
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 APIsIf 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. Figure 1.2. You should understand the technology components and service APIs that constitute the J2EE platform.
Java Servlet Technology 2.3Java 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.2JavaServer 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.0The 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:
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 APIThe 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:
For these reasons, it is important that you select the appropriate JDBC driver suited for your application environment. Java Message Service 1.0The 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:
Java Transaction API 1.0The 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:
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.2Email 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.0The 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.0The 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. 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:
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 APIThe 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.1eXtensible 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. 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.0JAAS extends the security architecture of the Java 2 Platform (Standard and Enterprise Edition) by providing the following easy-to-use mechanisms:
J2EE Application Programming ModelIn 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 ComponentsJ2EE 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 :
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:
Embracing J2EE component-based development offers the following benefits:
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 ArchitectureThe J2EE platform uses a multi-tiered distributed application model where
The tiers of a multi-tiered J2EE environment are defined as follows:
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. Figure 1.4. The J2EE three-tier architecture.
J2EE Compatibility Test SuiteThere 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
|