HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML

Last month's article "J2EE As the Platform for EAI" (JDJ, Vol. 7 issue 3) discussed the suitability of the J2EE platform for EAI (Enterprise Application Integration). This article addresses more advanced integration topics, particularly transaction and security, support for Web services, and an overview of J2EE application servers.

EAI enables concurrent access to data and functionality shared between disparate existing applications while maintaining integrity, consistency, performance, and recoverability. Transactions play an important role in ensuring integrity, consistency, and recoverability.

Support for Transactions
When talking about integration we have to support transactions that span existing applications, databases, and newly developed application components. In general, the following are the most frequently seen scenarios:

  • A virtual component or a wrapper in the business component tier accesses several different databases (in the EIS tier) within a single transaction.
  • Several virtual components are included within a transaction and access several different databases within a single transaction (see Figure 1).

    Figure 1
    Figure 1

  • A virtual component calls different EIS systems within a transaction.
  • Several virtual components deployed in different containers call different EIS systems within a transaction (see Figure 2).

    Figure 2
    Figure 2

  • A combination of the above - several virtual components may call a combination of EIS systems and access several different databases within a single transaction.

    For each scenario it's necessary to figure out how transactions can be propagated from the J2EE to the existing systems and back. Things get more complicated because some of the existing databases and applications may already provide transactional support.

    Local and Distributed Transactions
    In general, a transaction includes several resources (such as components, databases, and existing systems). Each resource taking part in a transaction needs a resource manager, which manages access to one or more resources. The whole transaction, however, is managed by the transaction manager. Figure 3 illustrates these relationships.

    Figure 3
    Figure 3

    The transaction manager coordinates different resource managers. Therefore, it has to establish and maintain the state of the transaction. This state is managed by the transactional context, which associates the transactional operations on the resources. All resources that participate in a transaction share the same transactional context. Usually the transaction manager also takes care of propagating the transactional context between the resource managers. Resource managers, however, have to notify the transaction manager about their participation and the current state of the transaction. Based on this information, the transaction manager decides whether to commit or roll back the transaction. In a commit or rollback, all resource managers take part.

    In simple applications that span only a single resource (a database, for example) we need only one resource manager. We call such relatively simple transactions local transactions. Unfortunately, in complex integration scenarios we usually aren't that lucky.

    We have to use transactions that span different systems, as shown in Figure 3. These are called distributed transactions. Such transactions are more complex than local ones and require a special algorithm, the two-phase commit, to commit them. It performs the voting phase and the commit phase in a complicated sequence of interactions between the transaction manager and resource managers. Fortunately, there are two standards for distributed transactions that enable transactional interoperability between different products:

    • ISO TP model
    • X/Open DTP (Distributed Transaction Processing) model
    The ISO TP model doesn't have many supporters and therefore doesn't play an important role in distributed transaction processing. Far more important is the X/Open DTP Model, which has established itself as a standard among vendors providing transactional systems. X/Open DTP specifies two interfaces between the major elements of a transactional system:
    • TX interface: The interface between application components and the transaction manager, it enables an application component to join a transaction.
    • XA interface: This defines the interaction between the resource managers and the transaction managers. This interface enables the cooperation of different resource managers, implemented by different resources, to take part in a single distributed transaction
    Most widely implemented commercial products support the X/Open DTP standard, including:
    • DBMSs such as Oracle, Informix, Sybase, and MS SQL Server
    • TP monitors such as Encina, Tuxedo, and TopEnd
    • MOMs such as IBM MQSeries and MS MQ
    • Distributed-component models such as CORBA (through CORBA Object Transaction Service)
    How J2EE Supports Transactions
    You probably know that J2EE supports transactions in the Web component tier, the business logic tier, and the EIS tier. The J2EE specification doesn't require support for transactions on the client tier. Although J2EE supports transactions in the Web component tier, it's a much better idea to delegate the transactional work to the business logic tier.

    J2EE also provides two ways to specify transactions. It supports programmatic and declarative transactions. With declarative transaction demarcation, the J2EE components are marked as transactional at deployment. The container (the EJB container, for example) is responsible for determining transaction boundaries.

    With programmatic transaction demarcation, the transaction clients demarcate transaction boundaries themselves. In most cases, the transaction clients associate the transactional context with the thread, which executes the transactional operations.

    To access the transaction service functionality, J2EE has the JTA (Java Transaction API), which provides an abstraction layer on top of the JTS (Java Transaction Service). JTA specifies standard interfaces through which different resources participating in a transaction can communicate. The abstraction layer provided by the JTA enables the platform to choose which JTS implementation it will use. The implementation, which is typically provided by the application server, is transparent to the application components because the application components don't interact with the JTS directly.

    The really important fact for integration is that the JTS is compliant with the CORBA Object Transaction Service (OTS) 1.1. More precisely, it's the mapping of the CORBA OTS to Java. It propagates transactions using the IIOP protocol. As I've already mentioned, CORBA OTS provides support for distributed transactions, so we can infer that the JTS also supports them.

    However, the J2EE specification 1.3 doesn't require a J2EE implementation to support distributed transactions. Fortunately, most widely implemented J2EE application servers, such as BEA WebLogic, IBM WebSphere, and Oracle 9iAS, already provide support for these transactions.

    Existing Systems and Transactions
    Support for distributed transactions is thus required for serious integration of transactional behavior between the J2EE and existing transactional EIS systems that are X/Open DTP compliant; fortunately, most EIS systems are compliant. When we access such systems within transactions, they behave in accordance with other resources included in the transaction. They commit changes only if the whole transaction is committed; otherwise they roll back the results. Within such a transaction we can interoperate interactions with several EIS systems. The coordination and the propagation of transactional context is handled automatically.

    EIS systems that implement local transactions that aren't X/Open DTP compliant require more manual work to achieve transaction integration. Such transactions are managed by the resource manager of the underlying EIS; therefore the J2EE application server won't be aware of them and won't be able to control or influence them. With local transactions we have to commit or roll back each system explicitly and manually.

    A technique to manage this scenario is to use compensating transactions. For every system in which we use a local transaction, we have to define a compensating transaction with which we can undo the effects of a previously committed local transaction. Compensating transactions have to be implemented programmatically and they introduce a few problems:

    • They don't provide high enough isolation for clients accessing the EIS system. The transaction is committed and then reversed after some time. In the meantime, other clients can see the inconsistent state. Compensation transactions implement only the read uncommitted isolation level.
    • If the compensating transaction isn't successful, the state of the EIS system can become inconsistent.
    We have to be aware of these problems and provide application logic that will resolve these situations if they arise.

    Support for Security
    Security is another important topic for EAI. When defining the integration architecture, we have to ensure that existing applications remain secure and that we don't re-create functionality that already exists. However, we also have to ensure the integration of security mechanisms. Imagine an integrated information system in which each user has to use an application-specific way to authenticate and authorize. Using such a system would be pretty tedious, requiring users to log on several times using different username and password combinations.

    What we need is a way to propagate security contexts through integrated applications. In other words, we need a standardized security model that can handle a wide range of applications, establish an end-to-end security through the tiers, and provide a single authentication point for the user.

    As we know, Java has a policy-driven, domain-based security model. Java provides extension packages that were initially introduced as optional but have been integrated into J2SE 1.4, including:

  • Java Authentication and Authorization Service (JAAS): Provides a framework for authentication and authorization. J2EE 1.3 requires that J2EE application servers use JAAS in Web component and EJB containers, particularly to support J2EE connector architecture.
  • Java Secure Socket Extension (JSSE): Provides packages for enabling secure communications using SSL and TLS protocols and includes functionality for encryption, authentication, and message integrity.
  • Java Cryptography Extension (JCE): Provides a framework and implementation for encryption, key generation, key agreement, and MAC (Message Authentication Code) algorithms.

    Authentication is often performed in two steps. First, based on a password or some other secret information, an authentication context is created. This context stores the identity and can create proofs of identity. Second, the authentication context is used to do authentication with all involved entities. The important questions now become how we can control access to the authentication context, and how do we propagate it. Possibilities include the following variations:

    • Access to the authentication context is made available to all trusted components.
    • The caller can delegate the authentication context to the called component.
    • All processes started by the user that performed the authentication inherit access to the authentication context.
    The propagation of authentication context introduces a certain overhead. Therefore, we can set up so-called trusted environments in which the components can communicate without authentication. Such environments are called protection domains.

    In J2EE, the container provides the boundary on which the authentication is performed when outside callers try to access the components inside the container. However, the container boundaries aren't always the same as the protection domain boundaries. Often the Web component container and the EJB container form a protection domain in which the EJB container can trust the Web component container (see Figure 4).

    Figure 4
    Figure 4

    The authentication in J2EE is based on users, realms, and groups. Users represent people who use the information system. A realm is a collection of users who are authenticated in the same way. J2EE supports two realm types: default and certificate. Default realms are used to authenticate all clients except Web clients. Web clients have to use the certificate realm. Users of the default realm can belong to a group. A group is a category of users who share a certain role - customers or employees, for example.

    For authentication JAAS supports different models to be plugged in at runtime. This enables us to use an industry-standard authentication technology through all the integrated applications. Kerberos, the most commonly used authentication technology, enables single sign-on support for multiple applications. Kerberos is a network authentication service created by MIT. (For more information on Kerberos please see http://web.mit.edu/kerberos/www/.)

    JAAS, together with JSSE and JCE, enables us to build our own EAI security infrastructure. It allows us to wrap the existing applications in the same security process, using industry standards such as Kerberos for authentication, SSL and TLS for communication channel protection, and application-independent encryption engines.

    In EAI projects that involve integration of non-Java applications and resources, J2EE-based security may not always be sufficient to achieve end-to-end security. A solution is to use the CORBA security model, which can be used from Java as well as from applications written in other programming languages. It's beyond the scope of this article to go into the details of CORBA security, but more information can be found at www.omg.org.

    Another possibility is to use the Generic Security Services (GSS) API, developed by the Internet Engineering Task Force. GSS provides generic authentication and a secure messaging interface that supports pluggable security mechanisms. GSS version 2 is defined in a language-independent format. GSS applications can use different security mechanisms without having to make changes to the application itself.

    Java bindings for GSS are referred to as JGSS. The JGSS API is part of J2SE 1.4. JGSS allows Java developers to create uniform access to security services over different mechanisms, including Kerberos.

    You may wonder why we need the JGSS API. While it shares many features with JAAS and JSSE, JGSS has some features not present in the Java security model:

  • The JGSS API contains support for Kerberos as the key authentication mechanism, which allows single sign-on support. The JSSE API doesn't support a Kerberos-based cipher suite - it supports SSL/TLS only.
  • JGSS is a token-based API that relies on the application to handle communication. This allows an application to use the transport protocol of its choice to transport the tokens. JSSE allows only applications to use sockets.
  • JGSS allows the selection of encryption type, which allows applications to intersperse plaintext and cipher-text messages. JSSE and JAAS don't support this.

    I expect that JGSS will emerge as the standard API to use for security integration in EAI.

    Naming and Directory Services
    With an integrated information system, it becomes important to have a place to store environment-specific information in an application-independent way. Naming and directory services are widely used by many companies for storing information on any directory object in a computing environment, including components, computers, printers, persons, and networks. These services provide operations for creating, adding, removing, searching, and modifying these directory objects. The ubiquity of naming and directory services makes the selection of these services for integration a difficult task. Examples of naming and directory services and protocols include LDAP, NIS, NDS, DNS, SLP, and CORBA Naming.

    J2EE doesn't introduce a proprietary naming and directory service. Rather, it provides an abstraction interface, the Java Naming and Directory Interface (JNDI) API, that can be used to access practically any naming or directory service in use.

    To provide support for pluggable implementation, JNDI also specifies, in addition to the API, the service provider interface (SPI). This interface specifies the interfaces the provider of a naming and directory product has to implement in order to be used via JNDI (see Figure 5).

    Figure 5
    Figure 5

    More important, by using JNDI we can access and integrate naming and directory services that already exist in our information system. The prerequisite, however, is that they provide support for JNDI - which most products do.

    Web Services
    EAI is crucial for providing online, low-latency e-commerce solutions - sometimes e-commerce is the major reason for EAI. EAI architecture, as proposed, is already suitable for extension into the e-commerce field using Web services, which build on top of the J2EE integration architecture. To achieve sound architecture, we have to be aware that Web services differ conceptually and technologically from business logic components (such as EJBs, CORBA, and RMI). Web services focus more on the exchange of documents, while business logic components focus on operations. Document-based systems provide looser coupling and more asynchronous communication. This corresponds with technological differences. As we know, Web services are based on XML and use XML-based protocols and technologies such as SOAP, WSDL, and UDDI.

    Robust Web services can be built on top of the business logic components and should be considered highly interoperable entry points. One approach is to map the component interface to the Web service directly, which usually requires developing a dedicated component (usually an EJB component) to provide a suitable document-oriented interface. This approach is supported by the leading J2EE application servers, which provide tools to convert EJBs to Web services.

    The other approach is to build Web services on workflow-based models, where each Web service calls several business components and other resources to fulfill the request. This approach requires more development work and some knowledge of the corresponding APIs. As mentioned in my previous article, the corresponding Java APIs include JAXM, JAX/RPC, JAXR, and JWSDL. These APIs are still under development and aren't a standard part of J2EE 1.3. In the meantime, we have to use custom APIs provided by application server vendors.

    Web services are a promising technology and you may wonder why we don't use them for the whole EAI. The fact is that Web services as they now exist have some shortcomings: currently there is no support for transactions; the security is based on SSL/TLS only; and because Web services are an XML-based technology, they require more overhead for processing.

    Performance and Scalability
    Also an important EAI topic is the performance and scalability of the integrated information system. With EAI we place existing systems in a different environment and use them in ways they weren't designed for. Accordingly, it's important to test existing systems for performance and scalability before we decide how to reuse them in the integration architecture. If existing applications don't provide acceptable performance initially, we can't expect that the performance of the integrated system will be acceptable. Thus, we have to choose at the outset which existing applications meet our criteria and which don't. For those that don't, we have to find ways to improve their performance - for example, through hardware upgrades, software upgrades, tuning, or clustering.

    When integrated, existing systems will also be accessed remotely. In this sense we want to minimize the number of remote invocations and the number of layers through which calls are passed. Although I've recommended building the integration architecture in tiers, it's important to select implementation techniques carefully to minimize the communications overhead.

    To achieve good performance using the J2EE integration architecture, you should focus on many different elements:

    • Define the performance objectives.
    • Assess the performance of existing applications.
    • Design a sound integration architecture.
    • Start assessing the performance in the design phase.
    • Implement the integration architecture using performance optimal techniques.
    • Tune the integration infrastructure for performance.
    • Provide an adequate hardware platform.
    J2EE Application Servers for EAI
    Finally, we have to mention the selection of the J2EE application servers. We have to be aware that different servers comply with different versions of the J2EE platform specification and that some servers support value-added features. Some value-added features require the use of specialist APIs. Examples include support for Web services. Most application servers that support these features don't use JAX* interfaces (such as JAX/RPC and JAXM), but provide their own APIs.

    The most important value-added features that don't require us to use specialist APIs, but are instead based on declarative configurations, include:

    • Support for distributed transactions and two-phase commit
    • Load balancing
    • Replication and failover
    • Clustering
    • Performance optimizations
    • Connectors for integration with EIS systems (SAP R/3, PeopleSoft, etc.)
    • Connectors for management systems (SNMP, CA-Unicenter, IBM Tivoli, etc.)
    • Support for pluggable middleware, including JMS, JNDI, and ORB implementations, pluggable authentication modules (PAM), etc.
    • Support for automatic logging
    • Support for wireless clients
    • Support for hot deployment of Web and business logic components
    Some vendors, already recognizing the role of application servers for integration, have supplemented their J2EE application servers and focused them directly on integration. Many of them even specifically name them as such. Such integration servers provide more tools to access existing systems and often provide out-of-the-box support for technologies necessary for EAI.

    J2EE provides solutions for advanced EAI topics such as transaction, security, and naming and directory integration. The EAI architecture also can support Web services, and is actually the prerequisite for effective, low-latency e-commerce solutions.


  • Juric, M.B., with Basha, S.J., Leander, R., and Nagappan, R. (2001). Professional J2EE EAI. Wrox Press.

    Author Bios
    Matjaz B. Juric is the author of Professional J2EE EAI and coauthor of Professional EJB. He holds a PhD in computer and information science. [email protected]

    Ivan Rozman is the faculty dean at the University of Maribor and has many years of experience in EAI projects. He holds a PhD in computer and information science. [email protected]

    All Rights Reserved
    Copyright ©  2004 SYS-CON Media, Inc.
      E-mail: [email protected]

    Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.