The Standardized World of J2EE

The Java 2 Enterprise Edition is a successful attempt at defining a standard enterprise platform for the development of distributed component-based applications. The benefits and architecture of J2EE applications have been covered in the earlier chapters of this book. In this section we will be review the architecture from a slightly different, and much higher, perspective.

Consider Figure 10-1. It illustrates a high-level view of the main components of the J2EE architecture. Components form the building blocks of J2EE applications and consist primarily of Enterprise JavaBeans. If you consider the J2EE architecture of the components/container philosophy closely, you will find that an EJB is entirely encapsulated from the outside world. The component lives inside the "standardized world" of J2EE. By "standardized world" we mean that every interaction and invocation that the EJB component wishes to make (or has made upon it) is within a totally defined environment, namely, that of the EJB container and J2EE application server. There are also components that allow web interfacing and interaction with the J2EE platform: servlets/JSPs and web applications; and these components also live within the defined environment of the web container and J2EE application server.

Figure 10-1: The "Standardized World" of J2EE.

If either of these components wishes to utilize the functionality of an existing enterprise service such as message-oriented middleware (MOM), an enterprise relational database management system (RDBMS), enterprise directory server (such as LDAP), or e-mail via an SMTP server, there are defined J2EE standards for the interfacing with these services: message-driven beans and JMS, databases via JDBC, e-mail via JavaMail, and naming and directory services via JNDI. Hence the world for the J2EE-based component is "standardized" in that all the required interfaces are defined.

Let us now identify the main tasks of distributed component software in today's enterprise. We aim to identify the required standardized features and functionalities, which are summarized in Table 10-1.

Table 10-1: Requirements for distributed component software.

Requirement	Standardized	J2EE Offering
Connectivity to other standardized vendor-provided products/services such as databases, message queues, and directory services.	Yes	Handled via the many J2EE specifications such as JDBC, JMS, JNDI.
Development of custom, reusable components containing business logic.	Yes	Handled via the EJB component model.
Interface between the system and the Internet via HTTP and markup languages such as HTML.	Yes	Handled via the J2EE servlets, JSP, and web application technologies.
Connectivity to proprietary transactional enterprise resource planning systems (ERPs).	Yes	Handled via the J2EE connectors architecture, which allows for the connectivity and security/transaction context propagation between J2EE and ERP systems.
Connectivity to other heterogeneous systems both internally, within an enterprise, and external to the enterprise.	No	Could be handled via custom message system, including CORBA ORBs and servlets. Legacy formats such as EDI also in use.

The Enterprise platform, that is, J2EE, is standardized and offers an excellent architecture for the first four items in the table. However, the final item can become a difficult task. We can break this item into two distinct problems: integration across/within an enterprise (also known as internal integration) and integration across multiple enterprises (external integration). We will now look at both of these items in more detail.

Internal Integration

Internal integration (see Figure 10-2) can be defined as the process of connecting multiple systems that belong to a single company or department. Both systems are well known and controlled and can usually be easily customized and extended to allow for integration. Integrating such systems poses a few challenges, including dealing with differences in platform, programming language, and the protocols used.

Figure 10-2: Internal integration.

External Integration

External integration (Figure 10-3) can be defined as the process of connecting multiple disparate systems that belong to differing companies (in a business-to-business, or B2B, scenario) or between two departments of a global company. The systems are relatively closed and isolated from one another, and interfaces between them are required to be explicitly defined; furthermore, technologies used between the systems may be incompatible and difficult to alter. Suppose, for example, that a merger takes place between two companies—Intergalactic Enterprises and Stellar Transport, say—that have disparate systems,. Intergalactic Enterprises has deployed an enterprise-wide infrastructure based on Microsoft technologies, while Stellar Transport has invested similar amounts of time and resources in a J2EE-based architecture. If the two companies merge and wish to integrate their systems, neither company expects to have to migrate its system to a different architecture. The same scenario can also be derived from a B2B scenario in which two trading partners wish to automate invoicing and delivery information between their systems.

Figure 10-3: External integration.

With internal integratiom, because the same company owns and controls all systems they run, they have control over both systems. With external integration, because integration involves another third-party system, the company has control of only one system. Moreover, with external integration there is the added issue that transactions may have to run over the Internet.