Next Generation Application Integration: From Simple Information to Web Services

2017-07-07 02:10:07

To this point, we've devoted our discussion of transactional middleware to general terms, highlighting the features and functions of TP monitors as prime examples of transactional middleware. We should never underestimate the importance of TP monitors. Even so, we must also consider a different breed of transactional middleware.

Application servers not only provide a location for application logic and interface processing, they also coordinate many resource connections (see Figure 7.4). They are typically Web-enabled and bring transaction processing to the Web through any number of mechanisms (see the tidbit "Considering Object State Management and Application Servers" later in this section).

Figure 7.4. Application servers provide both a location for application logic and a mechanism to coordinate connections to remote resources.

The new application servers tend to support Java as both the native language and the development model (although in different ways) as they progress toward the new world of Enterprise JavaBeans, or EJB (described in the section "Enterprise JavaBeans" later in this chapter).

Application servers take many existing enterprise systems and expose them through a single user interface, typically a Web browser. For example, application servers can easily externalize information contained in mainframes, ERP applications, and even middleware without a user interface. As a result, developers can gain all the application development capabilities they require, including a programming language and an integrated development environment. This makes application servers ideal for Portal-Oriented Application Integration.

As always, technology gives and technology takes. Where there are strengths, there are also weaknesses. Application servers are not strong players in back-end integration or application-to-application integration, when the information is rarely externalized through a user interface. This weakness is a direct result of the need to code all parts of the information extraction, transformation, and update process, typically through traditional transaction semantics.

Because application servers were created for Web-based transactions and application development, their benefit to application integration is obvious. What makes them invaluable in this context is their ability to perform back-end integration (to bind together several source and target applications through a series of connectors provided by the application server vendors for example, SAP, PeopleSoft, Baan, relational databases, and middleware).

In addition to being a mechanism for integration, application servers provide an up-to-date approach to sharing methods. Unfortunately, each application server has its own approach to how this happens. Because of this "individuality," making sound decisions about the selection of an application server or application servers for an application integration project requires an understanding of both the category of features and the problem at hand.

Evolving Transactions

Application servers have been used extensively over the years, as have enabling mechanisms such as distributed objects. However, new demands have forced us to re-examine this paradigm, adding up-to-date products such as those built around the notion of processing components with transactionality. This re-examination and development provides us with a dynamic window into the evolution of the technology. And what we see is that the progress is uneven. Despite the development of application servers, TP monitors remain far ahead in performance and reliability. By the same token, application servers have surpassed TP monitors in certain respects, such as having more advanced features (an integrated development environment, for example).

Taking the strengths and weaknesses of application servers into account, we can clearly see their benefit. By placing some or most of the application logic on a middle tier, developers can exert increased control over the application logic through centralization. Such placement increases the ability to scale the application through a set of tricks, such as database multiplexing and load balancing, described previously. The end result is a traditional three-tier client/server computing model (see Figure 7.5), consisting of a presentation layer (the part that presents the information to the client), an application layer (the middle-tier application logic), and a data layer (where the data resides).

Figure 7.5. Application architecture, using an application server.

Considering Object State Management and Application Servers

Most application servers use a stateless model to provide component processing environments, enhancing scalability through the recycling of an object in the memory of the application server. Rather than destroy and re-create objects for every connected node, the application server maintains a pool of objects to hand out to any external process-requesting service.

The stateless component model has the advantage of improved scalability. Unfortunately, it also has two major disadvantages: First, it does not support multiple references to the properties of an object. As a result, it does very little to support object reuse through the object-oriented programming model. Second, it has to create a new object for each database request, resulting in a performance hit when object data is loaded from a back-end database.

The two dominating standards are Java, with its Enterprise JavaBeans initiative (also closely tied to CORBA), and COM+, integrating with products such as Microsoft Transaction Server (MTS) and Microsoft AppCenter.

Enterprise JavaBeans

The primary difference between application servers and traditional transactional middleware (such as TP monitors) is that application servers can function around the notion of transactional components. Nearly every application server that uses this transactional component-type architecture looks to employ EJB as the enabling standard. However, each application server accomplishes this in its own special way.

This awkward reality is partially the result of standards that are still in a state of flux. Sun is working hard to address the issue of an EJB standard and build a certification process.

Although EJBs are really Java-enabled middleware (and therefore a topic to be covered later), their discussion is appropriate in the context of application servers because they add the most value to transactional middleware.

The EJB specifications (see www.java.sun.com) define a server-side component model for JavaBeans (see Figure 7.6). EJBs represent specialized JavaBeans that run on a remote server (known as the EJB container). From the architecture point of view, EJBs look very similar to distributed objects such as COM and CORBA.

Figure 7.6. EJBs define a server-side component model.

EJBs use the same architecture as traditional JavaBeans. They can be clustered together to create a distributed application with a mechanism to coordinate processing that occurs within the JavaBeans. As such, they reside on application servers, which process the beans as transactional components.

The EJB model supports the notion of implicit transactions. EJBs do not need to specify the transactional demarcation point in order to participate in distributed transactions. This feature represents an essential benefit to the model. The EJB execution environment automatically manages the transaction on behalf of the EJBs, using transaction policies that can be defined with standard procedures during the deployment process. Of even greater benefit, transactions may be controlled by the client-side applications.

Although the EJB model defines the relationship between an EJB component and an EJB container system, EJBs do not require the use of a specific container system. Any application execution system (such as an application server) can be adapted to support EJBs by adding support for services defined in the EJB specification; services that define the specified relationships between EJBs and a container. The application execution system also provides a portability layer. As a result, EJBs can run in any execution system (EJB container) that supports the EJB standard.

An EJB execution system is called an EJB Server. It provides a standard set of services to support EJB components. EJBs and the EJB Server are analogous to traditional transactional systems. Thus, an EJB Server must provide access to a standard distributed transaction-management mechanism.

An EJB container brings into play the management and control services for a class of EJB objects. In addition, this system provides life-cycle management, transaction control, persistence management, and security services. The larger concept and benefit here is that EJB allows a single vendor to provide both the EJB Server and the associated EJB container.

Transactional COM+ (Using AppCenter)

In a strategy similar to the one employed with EJBs, Microsoft plans to support transactionality through COM+ and AppCenter. AppCenter provides an environment to process transactional COM+ components along with traditional TP monitor features, such as support for ACID, database access, and recoverability.

The sophisticated application server architecture of Windows XP is a notable plus, as are the hundreds of application development tools available for the Windows 2000 platform. However, this may very well be a comment more about what runs on Windows XP than how well something runs.

Component-Dynamic Load Balancing within Windows 2000 supports up to eight connected application servers (nodes). This enables application developers to process one or many COM+ components across a cluster using AppCenter Server. In reality, an AppCenter Server is a Microsoft Transaction Server for transaction support and a Microsoft Message Queue (MSMQ) server for message queuing support all rolled into a single distributed COM+ processing environment. AppCenter acts as a router, using server response time to find the least-busy server to create COM+ components for processing. As a result, it balances the load.

The market for AppCenter consists of those organizations seeking to support both Web- and enterprise-based application processing loads that exceed a single server or symmetric multiprocessing (SMP)-based server.

Component-Dynamic Load Balancing is built to compete with the high-end application servers. These products work primarily with the Enterprise JavaBeans standard from Sun, providing a similar component-processing model on both Microsoft and non-Microsoft platforms. Unfortunately for Microsoft, MTS never got the traction it had hoped to receive. AppCenter is Microsoft's attempt to roll over the existing leaders.