The term architecture is used in many contexts. In this chapter, it is used to describe the components of the Sun Java CAPS Suite and how they relate to each other and to the environment in which they operate. Java CAPS is placed in the context of enterprise systems. Its architecture and components are defined, and their roles and relationships are described. Finally, solution development stages are described and their outputs placed in the context of the Java CAPS development and runtime environment.
Early versions of Enterprise Application Integration (EAI) tools, including those from STC (SeeBeyond under its earlier name), implemented a hub-and-spokes EAI model. A central Message Broker provided all transformation and management capabilities. Such implementations, while reasonably easy to manage, deploy, and maintain, suffered from resiliency and scalability limitations. A single server was a single point of failure. The higher the throughput required, the bigger and more capable the hardware platform had to be. Multithreading was typically not supported, so the Message Broker was not able to leverage multiprocessing capability of the hardware platform, if such was available. If the requirements exceeded hardware capability, multiple deployments on separate hardware platforms were required, likely with some form of a messaging bridge between them. Each eWay Adapter and the Message Broker was deployed as individual processes.
Later versions of the SeeBeyond EAI suite were totally distributed. eWay Adapters had built-in transformation capabilities, and standalone transformation components (Business Object Brokers) were available. All these capabilities and components were tied together through the underlying queuing infrastructure and communicated with it, and with the management and control dashboard, using the Transmission Control Protocol (TCP). Each eWay Adapter and Business Object Broker (BOB) was a standalone process and thus could be deployed on any supported machine regardless of where all the other components were deployed. Solutions could scale by improving capabilities of high-end machines or adding multiple low-end machines, or both. With multiple independent processes on a single machine, hardware multiprocessing capability could be taken advantage of if available.
Having many independent processes as part of an EAI solution was not always an advantage. Each process had its own hardware resources allocation requirements. Creation and destruction of processes is more expensive in terms of machine resources than creation and destruction of threads within a single process. Context switching and paging, associated with execution of many concurrent processes, are also expensive.
The most recent releases of the SeeBeyond ICAN and the Sun SeeBeyond Java CAPS platforms are Java EE based. Both use Java EE Application Server Containers to deploy integration components, implemented as Enterprise Java Beans (EJBs), taking advantage of container services, resource pools, multithreading, and other optimizations not available in earlier products.
The architecture of the EAI product greatly influenced the kinds of integration styles that could be used and the way in which scalability and resiliency were implemented. The capabilities of the external applications to be integrated also greatly influenced the kinds of integration styles that could be used and the kinds of Java CAPS components required by the integration solution.
An integration solution operates within the context of a wider enterprise infrastructure and interacts with its various components. This context is defined by the external systems that the solution connects and influences interactions and interfaces that can be implemented.
While all manner of activities might take place inside an integration solution, messages upon which it acts typically come from one or more external systems and are typically destined for one or more external systems. Figure 2-1 diagrammatically depicts the Java CAPS solution context showing various components a Java CAPS solution might include.
Java CAPS provides numerous JCA-compliant Adapters (eWays) for interaction with external systems, including both prepackaged adapters for major ERP systems, such as SAP or PeopleSoft, and generic adapters for interaction with technical infrastructure, such as a TCP/IP eWay or Batch eWays [Batch_eWay] with support for FTP, SFTP, and local file system access.
With increasing deployment of Web Services and Web Services enablement of applications, Web Services invocation is becoming one of the accepted means of interaction with systems. Java CAPS can both invoke and consume Web Services as means of integration with external systems. eInsight Business Process Manager is in fact a BPEL4WS implementation [BPEL4WS], well suited for Web Services orchestration and development of Composite Applications. With Java CAPS release 5.1, Java Collaborations can also be exposed as Web Services and, as of release 5.1.3, there is built-in support for Java Collaborations to invoke Web Services without resorting to third-party solutions like the Axis framework.
A number of JMS implementations from various vendors are available as either standalone messaging solutions or as parts of suites. The Java CAPS Suite can interact with these JMS solutions either via direct support—for example, for the IBM WebSphere MQ JMS implementation, via third-party–provided JMS API libraries—or via vendor-specific eWays.
Integration with other information resources is supported through other generic and specialist eWay Adapters like Oracle, Sybase or DB2 databases, COM/DCOM, TCP/IP HL7, or HTTP/S.
Ultimately, Java CAPS solution can interact with any technology infrastructure that supports standard message-exchange mechanisms or for which a Java or a C/C++ Application Programming Interface (API) library exists.
Java CAPS provides integrated deployment and JMX-based runtime monitoring and management facilities. An enterprise might require the application integration solution to also integrate with the enterprise asset management and operational monitoring environment. The Suite can provide information to enterprise asset management solutions such as IBM Tivoli or CA Unicenter via Simple Network Management Protocol (SNMP) traps or other mechanisms such products support. From the standpoint of the Suite, these systems could also be considered external systems.
Java CAPS 5.1 completely separates the design time and the runtime environments. Figure 2-2 shows delineation between the design time and the runtime environments and various components each environment might include.
The design time environment consists of the Repository Server and the Enterprise Designer Integrated Development Environment (IDE).
The Repository stores all design time artifacts, both installed components and custom components, developed as part of integration solutions. The Repository Server is supported on a number of operating systems, including Solaris, Windows, and Linux.
The Enterprise Designer, a NetBeans-based IDE, is the development tool containing integrated editors for all artifacts that may form a part of a Java CAPS solution. All Java Collaborations, eInsight Business Processes, connectivity maps, deployment profiles, environment components, and other objects supported by other elements of the Java CAPS suite are designed using the Enterprise Designer. The Enterprise Designer, through the Repository, supports a fully featured Version Control System that provides both branching and tagging, among other features.
Note
The Enterprise Designer (eDesigner), through Java CAPS version 5.1.3, is supported only on the Windows operating system platform.
When building Web Services implementations, the Universal Directory, Discovery, and Integration (UDDI) Registry, optionally installed during Java CAPS installation, can be used to publish information about the Web Services implementation, including the location of the Web Services Description Language (WSDL) interface specification, at application build time.
Both developer authentication information and external systems configuration information can optionally be stored in an Lightweight Directory Access Protocol (LDAP)-based directory.
Not shown in the diagram are external systems, like relational databases or business applications, which Object Type Definition (OTD) Wizards may access at design time to create OTDs based on the metadata maintained by them.
The outcome of the development process, an Enterprise Application, can be built using the eDesigner or a command-line build tool. Output of the build process, the Enterprise Application Archive (EAR) file, can be deployed to the runtime execution environment using one of a number of methods. The choice of the method depends to some extent on the developer, to some extent on the target Application Server, and to some extent on the enterprise release management policies.
The runtime environment consists of a number of components that can be deployed over a collection of physical machines.
Logical host, the name that is a holdover from the previous release of the product, roughly corresponds to the Application Server Instance. It consists of an Application Server instance and an optional JMS Message Server instance.
EAR files are deployed to the Application Server, which provides all the runtime services expected of a Java EE container. The JMS Message Server is the messaging infrastructure that Enterprise Applications can use to pass messages among themselves. As of Java CAPS 5.1.3, the Sun SeeBeyond Integration Server 5.1 (which is a version of the Sun Application Server 8.0 Platform Edition), the Sun Application Server 8.2 Enterprise Edition, and the BEA WebLogic Application Server 9.1 are supported as target application server containers for Java CAPS Enterprise Applications.
A number of JMS Message Server implementations can be used as messaging infrastructure. These include the default Sun SeeBeyond IQ Manager, the Sun Message Queue, the Sun JMS Grid 5.1.3, and the IBM WebSphere MQ 6.0.
Each supported Application Server comes with its own, typically Web-based, configuration application. The Sun SeeBeyond Integration Server provides an Integration Server Administration Console, loosely based on the Sun Application Server 8.0 Administration Console application. This console allows configuration of both the Sun SeeBeyond Integration Server and the Sun SeeBeyond IQ Manager (JMS Message Server).
Runtime configuration information can be provided to Enterprise Applications in one or both of two ways. At design time, eWay Adapters and other configurable components can be provided with fixed configuration information. Enterprise Archives will carry this information embedded in various descriptors and will use it at runtime. An LDAP-based directory server can also be used for storing configuration information. Rather then embedding configuration literals, the configured properties embed LDAP references to directory entries containing configuration values. At activation time, when the Application Server starts the application, LDAP references are resolved to actual values and are used for component configuration.
Note
While using LDAP for storing configuration information increases flexibility, bear in mind that, at least through Java CAPS 5.1.3, only string values are supported. Configuration properties, such as port numbers, that require numeric entries, cannot be referenced from LDAP. All configuration entries are stored in an LDAP directory in clear text.
Java CAPS and its Enterprise Applications support Java Management Extensions (JMX). Java CAPS provides monitoring and management of the runtime environment through the Enterprise Manager infrastructure. Unlike in its predecessor, Java CAPS Enterprise Manager is a standalone management agent that directly communicates with Application Servers, JMS Messages Servers, and runtime solution components. It does not access design time components, like Repository, to which ICAN 5.0 used to require access.
The Enterprise Manager’s Web-based interface can be used to dynamically add Integration Servers and Application Servers to be monitored and managed. The Sun SeeBeyond IQ Manager can be managed and monitored through the Enterprise Manager. Other JMS Message Server implementations are also integrated into the monitoring and management interface, but some restrictions may exist.
The Sun JMS Grid, in addition to being integrated into the Enterprise Manager monitoring infrastructure, provides its own configuration, management, and monitoring infrastructure. The Sun Message Queue implementation is typically managed through the same interface as the Sun Application Server with which it is integrated.
Because Java CAPS supports a number of Application Servers from different vendors, a single Enterprise Application can be, with some care, designed to be deployed to different Application Servers and to use different JMS Message Servers. To appreciate how that care can be exercised, it is helpful to understand the stages in which Java CAPS solutions are developed and what deployment decisions are made at each stage.
It is assumed that you have been exposed to Java CAPS and the development process. If not, “Hello Java CAPS World” in Part II (located on the CD-ROM that accompanies this book) may provide a starting point.
A typical Java CAPS solution consists of one or more eWay Adapters, what [EIP] calls endpoints, one or more message routers, translators, channels, consumers, and other components that vary from solution to solution in kind and in number.
The development process for a single deployable Java CAPS solution proceeds through three stages. In the first stage, OTDs, Collaborations, Business Processes, and other objects that vary with Java CAPS product are developed. These define data structures and processing logic in a manner that typically does not have dependencies on the physical environment in which the solution will ultimately run. In some cases, even the specific properties of Endpoints are not preset. The most notable examples of this are JMS Destinations. Java Collaborations and eInsight Business Processes do not embed the knowledge of what kind of JMS Destinations they will use, whether queues or topics.
Note
At the connectivity map design time, no decisions are made as to which Application Servers and which JMS Message Servers will provide the runtime environment for the solution. Different Application Servers and different Message Servers can be used for different parts of the same solution, and a solution described by a single connectivity map can be deployed to different Application and Message Servers.
In the second stage, one or more connectivity maps are created. These collect logical components, connect them to form message routes, name external systems connectors, and, in the case of JMS Destinations, specify the types of JMS Destination that will be used. Some other physical decisions are made at this stage and embedded in connectivity maps. Java classes used to implement specific functionality, bean pools sizes, names of directories and files, enveloping schemes, servlet names, and similar properties that, while related to the physical environment, do not predicate target Application Server or target Message Server environments are also configured in this stage.
Note
Certain eWay Adapters, which are platform specific, may restrict the choice of platforms to which a Java CAPS solution can be deployed. One of the most notable examples of this is the COM/DCOM eWay, which can be deployed only to a Microsoft Windows environment. The decision to use the COM/DCOM eWay immediately makes the solution that uses it platform specific.
In the third stage, Collaborations, Business Processes, JMS Destinations, and their relationships expressed through connectivity maps must be associated with physical resources and packaged into Enterprise Archives. In Java CAPS, physical resources are expressed as collections of Application Servers, Message Servers, and external systems containers in one or more environments. Application Servers, Message Servers, and external systems connectors are configured to be associated with physical machines by host names, port numbers, user credentials, contexts, paths and other attributes that vary from resource to resource.
Note
In Java CAPS, at most one Sun SeeBeyond IQ Manager JMS Message Server can be associated with a logical host even if the Enterprise Designer Environment allows configuration of more than one. This is because the Enterprise Manager can only interact with one and the Application Server Domain can only start one. It is possible to configure additional Sun SeeBeyond IQ Managers under the single logical host, but each such IQ Manager will have to be associated with a different Application Server Domain. This ability can be used to configure “Shadow IQ Managers” for the purpose of implementing a JMS Messaging Bridge between independent installations, for example, Java CAPS and SRE or Java CAPS and ICAN.
Given a collection of external resources in the environment, the deployment profile is the mechanism by which logical components of the solution are mapped to physical resources.
Note
Deployment profile is the configuration component that determines not merely which instance but also what kind of an Application Server or a JMS Message Server will be used at runtime.
Note
The same logical solution can be built for deployment to different physical environments merely by creating a deployment profile associated with the specific Java CAPS environment and building the solution.
Note
So long as care is taken to ensure that connectivity map configuration properties are appropriate across environments, the same solution can be built for deployment to development, testing, user acceptance testing (UAT), or production without the need to change any of the development artifacts.
Let’s imagine that a solution was developed and deployed to an infrastructure that uses the Sun SeeBeyond Integration Server and the Sun SeeBeyond IQ Manager JMS Message Server. Some time later a need to improve resilience properties of the solution was identified. It was decided that the Sun Application Server 8.2 Enterprise Edition and the Sun JMS Grid, which provide the clustering support, would address that need. Both products were installed and configured. It is merely necessary to define a Java CAPS environment that includes the Sun Application Server 8.2 and the Sun JMS Grid, create a deployment profile associating the logical solution with the new physical environment, build the EAR file, and deploy. The original logical solution, without any changes, will operate in the new environment.
Note
If care was taken to ensure that no external systems configuration settings will clash, the same EAR file can be deployed to any number of Application and Message Servers of the kind for which the application was built. To elaborate, the same external Oracle database can be accessed concurrently by any number of instances of the Enterprise Application, but the same file in the same directory should not be.
Note
An Enterprise Application can only be deployed to the same kind of Application and Message Server as the ones for which it was built. To elaborate, an application whose components are associated, through the deployment profile, with the Sun SeeBeyond Application Server and the Sun JMS Grid Message Server cannot be deployed to the Sun Application Server 8.2 Enterprise Edition and the Sun Message Queue. To obtain an Enterprise Archive suitable for the new environment, simply create a new environment in the Enterprise Designer, create a new deployment profile, and build.
The final outcome of the three-stage development process is the Enterprise Archive, the deployment, and execution unit. It contains all components that the Enterprise Application will require at runtime.
This chapter described basic components of the Sun Java CAPS Suite required to implement application integration solutions, how they relate to each other and to the environment in which they operate. Java CAPS was placed in the context of an Enterprise IT infrastructure. Its architecture and components were defined, and their role and relationships were described. Solution development stages and their outputs were described and placed in the context of Java CAPS development and runtime environment.