Chapter 9. TIBCO ActiveMatrix^®

The TIBCO ActiveMatrix Product Suite

The TIBCO ActiveMatrix^® (AMX) product suite is a family of related products (Figure 9-1). This chapter provides an overview of these products and their architecture.

Figure 9-1. The ActiveMatrix Product Suite

The cornerstone of the suite is the TIBCO ActiveMatrix^® Service Bus, which provides the foundational infrastructure for building solutions based on the service-component architecture (SCA) concept. TIBCO ActiveMatrix^® Service Grid builds on this foundation, adding a number of implementation types that can be used for implementing components. TIBCO ActiveMatrix^® BPM adds support for business process management, built on this same framework.

TIBCO ActiveMatrix BusinessWorks™ is an integration and service engine with a graphical programming interface that can be deployed either stand-alone or within the ActiveMatrix Service Bus. The TIBCO ActiveMatrix adapters provide lightweight interfaces to many types of external systems. All adapters can be deployed stand-alone, and some can be deployed within the ActiveMatrix Service Bus.

TIBCO ActiveMatrix^® Lifecycle Governance Framework provides lifecycle management, repository, and registry capabilities to the enterprise. Since its operation is relatively independent of the rest of the ActiveMatrix product suite and its manuals provide a good overview of its usage, we will not discuss this product further in this book.

Basic TIBCO ActiveMatrix Architecture Patterns

The basic architecture pattern for ActiveMatrix deployments is shown in Figure 9-2. Components deployed within ActiveMatrix run in nodes, whose architecture will be examined in a moment. ActiveMatrix components interact with external components via external interfaces and, when deployed on different nodes, interact with each other via a private TIBCO Enterprise Message Service (EMS) instance.

Figure 9-2. Simplified ActiveMatrix Architecture Pattern

The internal structure of an ActiveMatrix node is shown in Figure 9-3. Components implement application functionality, while bindings provide the service and reference interfaces for these components. Interactions between components and bindings occur via the ActiveMatrix Virtualization Infrastructure that enables communications both within and between nodes. Bindings, in turn, rely on ActiveMatrix Shared Resources such as HTTP clients and servers for the realization of external communication interfaces.

Figure 9-3. ActiveMatrix Node Internal Structure

Implementation Types

A component is the basic unit of functionality in ActiveMatrix. ActiveMatrix offers a wide variety of technology choices (implementation types) for implementing components. Figure 9-4 presents an overview of the available implementation types as of the publication of this book.

Figure 9-4. ActiveMatrix Implementation Types

One of the simplest implementation types is Mediation. It is intended to serve as an intermediary between service providers and service consumers. For this purpose it provides simple and efficient content transformation, augmentation, and routing capabilities and has a simple graphical design interface that does not require coding. The Mediation implementation type is provided as part of the TIBCO ActiveMatrix Service Bus and its use is described in Chapter 14.

The Java and C++ implementation types provide the ability to implement functionality in their respective programming languages. The Spring implementation type enables functionality to be defined using the Spring framework. The WebApp implementation type enables the implementation of web applications with their own HTTP interfaces. These four implementation types are provided as part of the TIBCO ActiveMatrix Service Grid product.

TIBCO ActiveMatrix BusinessWorks provides the ability to implement composite applications and services using a graphical design interface rather than coding. Its implementations can be deployed either within a stand-alone engine or within the TIBCO BusinessWorks™ Service Engine (BWSE) implementation type in an ActiveMatrix node. The BWSE implementation type is provided as part of the TIBCO Active-Matrix BusinessWorks product.

TIBCO adapters provide lightweight mechanisms for interacting with external systems that can be easily configured through graphical design interfaces. Like BusinessWorks, adapter designs can be deployed as stand-alone adapter engines, and many of them can also be deployed within adapter implementation types in ActiveMatrix nodes. For TIBCO adapters that are deployable in ActiveMatrix, the required implementation type is included with the adapter product. The use of adapters is described in Chapter 15.

The last implementation type is the ActiveMatrix composite. A composite is an SCA construct that has services and references just like any other component (see Chapter 6). Its internal structure, however, comprises one or more components of any type, wired together. Any ActiveMatrix composite can be used as a component within another composite.

Binding Types

Bindings associate transports and protocols with component services and references. ActiveMatrix Service Bus provides a number of binding types (Figure 9-5). The SOAP protocol is supported with binding types for three different transports: HTTP, JMS, and the built-in ActiveMatrix Virtualization infrastructure. Note that the Virtualization binding only provides transport between components deployed within ActiveMatrix nodes.

Figure 9-5. ActiveMatrix Binding Type

The JMS binding type enables XML data structures to be sent and received over JMS transports. The EJB binding type enables interactions with enterprise java beans (EJBs) deployed in other environments. The Adapter binding type enables communication with TIBCO adapters. All binding types are provided with the TIBCO ActiveMatrix Service Bus product.

ActiveMatrix Node

The container into which ActiveMatrix composite assemblies are deployed is the node. The default node supplied with ActiveMatrix is a stand-alone executable built on a Java virtual machine (JVM). However, the node is architected in such a way that it, itself, could be deployed within another environment such as an application server. The current product literature should be consulted for an up-to-date list of node deployment options.

Nodes can contain components, bindings, and resources. When a component is deployed to a node it is deployed as an OSGi plugin that is installed into the node. The same is true for bindings and resources.

In order to keep the node lightweight, plugins are not installed into the node until a component (or binding or resource) is deployed to the node. At that time, the ActiveMatrix administrator automatically installs the needed plugins.

As you might imagine, the number of component, binding, and resource types yield many possible configurations for an ActiveMatrix node. Figure 9-6 illustrates a node with most of the possible plugins deployed in it. Although is it unlikely that you would have all of these elements deployed in one node in production, it does illustrate the possibilities. In fact, you might actually find this configuration in a development environment if you were playing with all of the component, binding, and resource types.

Figure 9-6. ActiveMatrix Node Example

Every ActiveMatrix node contains an element known as the policy agent. The policy agent serves as the control point for all policies that are enforced within the node. Policies (which will be discussed in Chapter 13) govern many aspects of node behavior, but some of the more common are access control policies governing authentication, authorization, and encryption. Illustrated in the diagram are the policy enforcement points (PEPs) where these policies can be enforced. Note that all interactions with component and binding types and most interactions with resources can be governed with policies.

TIBCO ActiveMatrix Service Bus

The foundational product in the ActiveMatrix product suite is the Service Bus (Figure 9-7). The major elements of this product are the ActiveMatrix Node, the ActiveMatrix Host, the EMS server, and the TIBCO Business Studio™ ActiveMatrix SOA Edition. The node is the container into which components, bindings, and resources are deployed. The ActiveMatrix Host is installed on every machine to which ActiveMatrix is deployed and serves as the administrative representative for ActiveMatrix on that machine. In the default configuration both the node and the ActiveMatrix Host are stand-alone executables, with each node being a Java Virtual Machine (JVM). In upcoming releases, both may be optionally installable in application servers.

Figure 9-7. ActiveMatrix Service Bus

Included with the node are the policy agent, all communication bindings, and the Mediation implementation type. The use of Mediation is described in Chapter 14.

While an EMS Server is installed with ActiveMatrix Service Bus, the license for Service Bus does not include a stand-alone EMS license. The EMS Server is only licensed for internal communications within the ActiveMatrix Service Bus. Any other use of EMS (such as using it for a SOAP over JMS transport) requires a separate explicit EMS license.

The TIBCO ActiveMatrix^® Administrator provides the deployment and run-time management for ActiveMatrix environments. From a run-time perspective, the administrator is actually an ActiveMatrix component that runs in a dedicated ActiveMatrix node. The administrator’s user interface is provided through a web browser interacting directly with the administrator. An associated database is used as a staging location for deployment and configuration information. ActiveMatrix Service Bus includes a HyperSQL database that can be used for this purpose, but its use is only recommended for development environments. Test and production environments should use a production database such as Oracle or Microsoft SQLServer.

TIBCO Business Studio ActiveMatrix SOA Edition provides the development environment for ActiveMatrix. Business Studio is based on Eclipse and uses the service-component architecture (SCA) graphical notation to specify ActiveMatrix designs.

TIBCO ActiveMatrix Service Grid

The TIBCO ActiveMatrix Service Grid product is built upon ActiveMatrix Service Bus and includes all the elements of Service Bus (Figure 9-8). Service Grid simply adds four implementation types: Java, C++, WebApp, and Spring. The Java implementation type makes it possible to create Java implementations of components that execute within an ActiveMatrix node, which is a Java run-time environment. The C++ implementation type makes it possible for components written in C++ to be accessed from within the Java-based ActiveMatrix node. The C++ code itself runs in a separate process. The Spring¹ implementation types allow Java code with the Spring extensions to run within the ActiveMatrix node. The WebApp implementation type allows web applications consisting of JavaServer Pages (JSP) and Java servlets to be run within the ActiveMatrix node. The WebApp implementation type exposes an HTTP (or HTTPS) interface with which browsers can interact. For more details on these implementation types, please consult the product manuals.

Figure 9-8. TIBCO ActiveMatrix Service Grid

ActiveMatrix Environments and Administration

Perspectives on Run-Time Environments

There are two common ways to think about organizing and managing the elements when it comes to deployment: logical and physical. The logical approach groups elements that are somehow related. This kind of grouping typically includes elements that are already deployed (from other projects) as well as the elements presently being deployed.

The physical approach groups elements by the specific physical environment in which they are running. Traditionally the environment has been a physical machine, but technology evolution has added virtual machines and potentially individual application server instances as alternatives.

IT shops require both kinds of grouping. Logical grouping lets you manage things from a functional perspective, while physical grouping helps you manage physical environments. For this reason, TIBCO ActiveMatrix supports both of these approaches.

Logical Environments

ActiveMatrix solutions are deployed into nodes. In a typical solution life cycle, the same design may be deployed into a number of different environments: development, test, production, and so on. To support this, ActiveMatrix provides the notion of an environment, which is simply a logical grouping of nodes (Figure 9-9). Each node belongs to exactly one ActiveMatrix environment. For the most part, when you see the term environment in ActiveMatrix documentation, it is this logical grouping that is being discussed.

Figure 9-9. ActiveMatrix Logical Environment Structure

Physical Environments

AMX nodes, of course, need to reside in some physical environment as well. Figure 9-10 shows how physical environments are organized in ActiveMatrix. A physical environment contains one or more ActiveMatrix hosts, each of which has a number of nodes associated with it. The host is an administrative entity that manages its associated nodes and all the related files in that physical environment. In the TIBCO documentation, the term instance refers to a physical environment.

Figure 9-10. ActiveMatrix Execution Environment Organization

In the base product configuration, a physical environment is simply an operating system instance, and hosts and nodes are stand-alone executables running under the operating system. The stand-alone nodes are individual java runtime environments (JREs). However, the product is architected in such a way that future releases may be able to support physical environments like application server instances. In such environments the host and its associated nodes will be logical entities within the application server rather than stand-alone executables. From a terminology perspective, in the ActiveMatrix product documentation the physical environment is commonly referred to as an instance.

Each node belongs to exactly one logical environment and exactly one physical environment. A single ActiveMatrix logical environment can have nodes in multiple physical environments. Nodes on multiple machines can be part of a single logical environment. Conversely, nodes belonging to multiple logical environments can be present in the same physical environment. If you have separate logical environments for development and test, you can have both development and test nodes on the same machine.

Administration Organization

Administrative tasks are managed by the TIBCO ActiveMatrix Administrator (Figure 9-11). The administrator is itself, an ActiveMatrix composite running in its own logical environment. This logical environment is called the System Environment and contains a single node called the System Node on which the administrator is deployed. This node runs in a physical environment, and the host in that environment is called the System Host. Note that this physical environment, particularly in development, may contain other nodes belonging to other logical environments as well.

Figure 9-11. ActiveMatrix Administration

Each host is associated with a single administrator. All administrative activity in a physical environment is carried out by the host associated with the administrator. This includes the creation, configuration, removal, starting, and stopping of the nodes belonging to that host (more on this later).

The administrator uses a number of supporting components: a credential server keystore, one or more databases, and one or two EMS servers. As indicated in the diagram, there are five different roles that can be played by the database. The actual database playing each role is specified individually so that anywhere from one to five databases can be used. Similarly, the EMS servers play two distinct roles, which can be played by either a common server or separate EMS servers.

ActiveMatrix File System Folder Structures

From time to time you may need to know where ActiveMatrix stores information in the file system. This section provides a quick overview.

There are two folder structures created by ActiveMatrix. One is the installation folder created when you install the product. All files created during the installation process are placed in this folder. You typically need only one installation folder, regardless of the number of machines on which ActiveMatrix will eventually run. On Windows, the default location is C:Program Files ibco.

The other folder is the configuration folder. Its location is specified when you run the TIBCO Configuration Tool (TCT) at the end of the installation process. This tool is used to create the ActiveMatrix Hosts and the System Node with its Administrator. The tool can place these components in any physical environment, and all files created during configuration are placed in this folder in that physical environment. The default location for the configuration folder is under C:Program Dataamx-3.

Figure 9-12 shows the configuration folder sub-structure. The region under amx-3/data/admin is divided into three sections. The first, amxadmin, contains all of the information actually managed by the administrator. The second, tct, contains all of the log files created by the TIBCO Configuration Tool. If you have any problems during the configuration process, this is the first place to look. The third, tibcohost, contains all of the information being managed by the TIBCO Hosts. In it you will find a sub-folder for each TIBCO Host that has been defined.

Figure 9-12. Configuration Folder Structure

In the folder for a specific TIBCO host you will find three sub-folders: The host folder contains the executable for starting the host, the host’s configuration, and all of the plugins needed by the nodes being managed by the host. The nodes folder contains a sub-folder for each node managed by the host. Finally, the tools folder contains the machine model, which defines the configuration of the host and all the nodes.

ActiveMatrix Solution Life Cycle

The architecture pattern for AMX administrative activities is shown in Figure 9-13. Solution designs are created in Business Studio and are exchanged with the administrator via the file system. The administrator directs hosts to take action by sending JMX² commands, and if the command requires access to a file, that file is retrieved via HTTP. Thus the interactions between the administrator and host are independent of the file system.

Figure 9-13. ActiveMatrix Administrative Architecture Pattern

The host takes action in several ways. It can interact with nodes via JMX commands, interact with the execution environment via its interface (e.g., command line), and interact with configuration files in the local file system. Status updates are sent to the administrator via the EMS monitoring and notification server. Nodes can read configuration files from the execution environment file system and send status updates to the administrator via the EMS monitoring and notification server.

An important element in the execution environment is the machine model (Figure 9-14). There is one machine model per host in each environment. The machine model is a file that contains the configuration definition for all of the nodes in the environment being managed by the host. When a node starts up or is commanded by the host, it reads the machine model to get its configuration. Much of this configuration is a list of the OSGI plugins (and features) that comprise the node. After reading the configuration, the node loads the required plugins and features.

Figure 9-14. Machine Model and OSGI Plugins in an ActiveMatrix Execution Environment

Figure 9-15 shows the ActiveMatrix solution life cycle from design through deployment. An ActiveMatrix solution is created in Business Studio and exported in the form of a distributed application archive (DAA) that contains an application template and is stored in the file system. The application template contains a root composite and a set of related configuration files, including nested composites, WSDL files, substitution variable files, and resource templates.

Figure 9-15. ActiveMatrix Solution Life-Cycle Process

From the administrator, the target logical environment for the solution is selected (or created, if necessary) and the DAA is imported. From this, the application is created and named. This application is a named copy of the root composite along with its substitution variables. The reason for this copy process is that it allows multiple instances of the same design (DAA) to be independently named, configured, deployed, and managed.

The imported DAA may also contain templates for resources required by the application (things like HTTP servers and clients, JMS clients, etc.). These templates, if needed, can be imported into the administrator. Note that in many cases you will already have identical templates in the administrator. In such cases it is not necessary to import the resource template.

Using the resource templates, the needed resources are created on the nodes to which the solution fragments will be deployed. The administrator accomplishes this by directing the relevant host to place the OSGI plugins and features in the execution environment, updating the node’s machine model, and either directing the node to load the required plugin or, in some cases, stopping and starting the node.

Once the resource instances are in place, the application can be deployed by the following sequence of administrator actions:

1. The administrator examines the application to determine if it needs any supporting OSGI plugins (such as the support for a particular implementation type).
2. It determines which fragments of the solution are to be deployed as OSGI plugins on the node.
3. It directs the hosts to position the required OSGI plugins and update the machine models.
4. It tells the hosts to command the affected nodes to re-read the machine model and load the needed plugins.
5. It directs the hosts to start the components.

Part of the deployment may include services that provide SOAP endpoints. Since the details of the endpoint may not be known until the service is actually deployed, after deployment it may be necessary to generate the WSDL containing the endpoint definition.

Deploying SCA Designs on ActiveMatrix Nodes

The ActiveMatrix Business Studio design environment uses SCA notation to specify ActiveMatrix designs. There are, however, many ways in which these designs can be deployed within an ActiveMatrix environment. This section explores, by example, the various deployment options.

Service and Component Deployment

Services (interfaces) and components (implementations) are independently deployable in ActiveMatrix. Figure 9-16 shows a simple design consisting of a single service and its implementation. In this example, both are deployed on a single ActiveMatrix node. Communication between them, by default, is fully contained within the node.

Figure 9-16. Single-Node Service and Component Deployment

An alternate deployment for this design is shown in Figure 9-17. Here the service and component are deployed on different nodes. Communication between them occurs via the ActiveMatrix EMS server. The administration of this server (i.e., the setup of communications between the service and corresponding component) is fully automated. No user action is required, even if the service or the component is moved to a different node.

Figure 9-17. Two-Node Service and Component Deployment

Service, Component, and Reference Deployment

Like services and components, references are also explicitly deployable. Figure 9-18 shows a simple design consisting of a single service, the component that implements it, and a reference that the component makes. In this example, all three elements are deployed onto a single ActiveMatrix node.

Figure 9-18. One-Node Service, Component, and Reference Deployment

Alternatively, this same design could be deployed to three different nodes (Figure 9-19). Once again, communication among elements deployed on different nodes occurs through the EMS server. The EMS server is automatically configured by the administrator as part of the deployment.

Figure 9-19. Three-Node Service, Component, and Reference Deployment

Complex Composite

The designs in the previous examples were relatively simple. Figure 9-20 shows a more complex design for presenting a comprehensive customer view across multiple systems. The service is implemented by a single component that references four different back-end systems to assemble the view.

Figure 9-20. Customer 360 Example Design

The simplest deployment for this design is the one shown in Figure 9-21. Here the component, along with the service and all of the references, is deployed on a single node. This is typical of a deployment during development.

Figure 9-21. One-Node Customer360 Deployment

Figure 9-22 shows the same design deployed on four different nodes. Here two instances of the Customer 360 component are deployed, sharing the processing of the Customer 360 Service requests. Both components share the same references to the external systems.

Figure 9-22. Four-Node Customer360 Deployment

TIBCO ActiveMatrix BPM

The TIBCO ActiveMatrix BPM product is built on top of the ActiveMatrix Service Bus and provides comprehensive support for architecting and implementing BPM solutions. There is much more to architecting these solutions than can be covered in this book, and this will be the subject of the upcoming Architecting BPM Solutions with TIBCO^®. Here we will confine ourselves to a brief overview of the product and a sketch of what a BPM solution looks like in the ActiveMatrix environment.

BPM Functional Organization

The functional organization of ActiveMatrix BPM is shown in Figure 9-23. The process manager oversees the execution of business processes, including the logic that determines the sequencing of activities and the conditions under which they are performed. The work manager oversees the execution of individual work tasks, including determining who is eligible to work on each task. The work manager can use information in LDAP for this purpose. Both the process manager and work manager provide web service interfaces to access their functionality.

Figure 9-23. ActiveMatrix BPM Functional Organization

Two types of browser-based interfaces are provided. The WorkSpace client is a BPM application based on the TIBCO™ General Interface technology. It provides a comprehensive user-configurable browser-based environment for starting business processes and viewing, opening, working on, and completing process tasks. The Openspace client is similar in terms of functionality but is based on the Google Web Toolkit (GWT).³ Both types of interfaces are extensible. Full custom user interfaces can also be built using the web services interfaces of the process manager and work manager.

The event collector gathers information about all BPM activity including user actions, process status changes, and work item status changes. It provides the raw data necessary to monitor and audit process execution at all levels of detail, ranging from individual events (e.g., a single user action, a single work item completion) to aggregate process statistics (e.g., the average completion time for a process, the peak execution rate for an activity).

BPM Solution Deployment

A BPM solution consists of two major composites: a solution composite and a BPM composite (Figure 9-24). The BPM composite contains the components that come predefined with the ActiveMatrix BPM product. It exposes five public web-service interfaces and a private client services HTTP interface. The public interfaces, described in the product documentation, provide access to the product functionality both for use by BPM solutions and external applications. The proprietary client services provide functional support for the Openspace and Workspace clients provided with the product.

Figure 9-24. ActiveMatrix BPM Deployment

Complementing the BPM composite is the solution composite. It contains all of the solution-specific components defined in the Business Studio design environments. These include process models, organizational models, and customizations to the user interfaces.

As of this writing, both the solution composite and the BPM composite have to be deployed onto a single distinguished ActiveMatrix node. It is anticipated that this constraint will be relaxed in an upcoming release, not only allowing these two composites to be deployed on separate nodes, but also allowing their sub-components to be distributed across multiple nodes. Please consult the product documentation for the latest deployment options. Aside from this constraint, ActiveMatrix BPM solutions are deployed in the same manner as other ActiveMatrix solutions.

Summary

The TIBCO ActiveMatrix product suite comprises a number of products, including the ActiveMatrix Service Bus, ActiveMatrix Service Grid, ActiveMatrix BusinessWorks, ActiveMatrix adapters, ActiveMatrix Lifecycle Governance Framework, and ActiveMatrix BPM.

The ActiveMatrix Service Bus node provides the deployment environment for the suite of products. It can house components, services, references, and resources. When instances on different nodes need to communicate with one another, they do so via an automatically configured TIBCO EMS server in the background. Components can be implemented in a variety of technologies, including Mediation, Java, C++, Spring, and WebApp. Service and reference bindings can be provided for SOAP with HTTP, JMS, or virtualization transports, XML over JMS, and EJB interaction.

ActiveMatrix deployments are organized into one or more logical environments, which are collections of nodes that are being administered together. Each ActiveMatrix administrator manages one or more environments. Nodes themselves are deployed into execution environments which are, at present, operating system instances. It is possible to have nodes from more than one logical environment present in a single execution environment. All administrator work in an execution environment is managed by a single TIBCO host. The host manages all of the nodes belonging to that administrator regardless of the logical environment to which they belong.

There is a lot of flexibility in deploying designs on ActiveMatrix nodes. A component and its associated services and references can all be deployed on a single node or, alternatively, each can be deployed on a separate node—without altering the design. This allows for maximum flexibility in support of fault tolerance, high availability, and load distribution.

ActiveMatrix BPM provides comprehensive support for building BPM solutions and deploying them on the ActiveMatrix platform. Both solution-specific and product-standard components are deployed and managed in the same manner as other ActiveMatrix components.