What is TIBCO ActiveMatrix ?
TIBCO ActiveMatrix software is a scalable and extensible platform for developing, deploying, and managing applications that conform to a service-oriented architecture.
TIBCO ActiveMatrix is a service platform for heterogeneous SOA. It gives enterprises a simpler and more productive way to deliver service-oriented applications by cleanly separating the applications from the technology details. This separation enables companies to incrementally add orchestration, integration, mediation, Java, and .NET for services to a unified runtime platform. Built-in governance allows companies to add policy management or govern the service lifecycle without having to change the applications.
With the TIBCO ActiveMatrix platform organizations are able to build next-generation applications that combine services created with disparate vendor technologies. The platform also replaces much of the technical coding involved in service creation, deployment and management, giving business analysts, architects, developers and administrators a common environment that streamlines application development. With built-in governance and management capabilities administrators have the control they need from a single, reliable console to easily deploy applications, apply policies without having to change the services, and add load balancing or fault tolerance to keep applications up and running.
Change in Product Name:
TIBCO Business Works has been rebranded as TIBCO Active Matrix Business works.
Active Matrix Business Works 5.6 is backward compatible with the earlier 5.x versions of business works
TIBCO ActiveMatrix Components
- Hibernate
- TIBCO ActiveMatrix Service Bus
- TIBCO ActiveMatrix Service Grid
- TIBCO ActiveMatrix BusinessWorks Service Engine
- TIBCO ActiveMatrix Administrator
- TIBCO ActiveMatrix BusinessWorks
- TIBCO ActiveMatrix BusinessWorks(TM) BPEL Extension
- TIBCO ActiveMatrix Adapter Service Engine for Database
- TIBCO ActiveMatrix Adapter Service Engine for Files
- TIBCO ActiveMatrix Policy Manager
- TIBCO ActiveMatrix Policy Agent
- TBCO ActiveMatrix Registry
TIBCO ActiveMatrix BusinessWorks
TIBCO BusinessWorks has been rebranded as TIBCO ActiveMatrix BusinessWorks. ActiveMatrix BusinessWorks 5.6 is backward compatible with the earlier 5.x versions of BusinessWorks. Some of the advanced features have been added to ActiveMatrix BusinessWorks 5.6 to support ActiveMatrix overall architecture. Some of the added features in ActiveMatrix BusinessWorks 5.6 are as below,
1. Service Container
TIBCO ActiveMatrix BusinessWorks now offers a new feature, service container in this release. Once you enable a service container, you can upload multiple EAR files in the same container. All the processes running in a service container are isolated and independent of each other. So if there is a need to add new services or upgrade the existing services in future, you can:
• deploy additional EAR in the same service container without bringing down all the running services.
• upgrade an existing process already running in a service container without affecting all the other processes running in the same service container.
2. Partner Service Invocation
To manage lifecycle of BW service through ActiveMatrix administrator, the BW services need to invoke and be invoked by other TIBCO ActiveMatrix components.TIBCO ActiveMatrix BusinessWorks introduces the following additional resource to invoke services from BW processes using abstract partner definitions.
3. Security Context Propagation from TIBCO Policy Manager
TIBCO ActiveMatrix BusinessWorks populates the security context for Service resource or SOAP Event Source activity with the security information sent by TIBCO ActiveMatrix Policy Manager.
4. JMS Local Transaction
TIBCO ActiveMatrix BusinessWorks supports JMS local transactions in the JMS plug-in. JMS local transaction is a new transaction group type into which JMS activities can be added. A JMS process starter can also be linked to this group. At runtime, the underlying JMS activities use the same transacted JMS session to provide transaction semantics for messages sent and received by the JMS activities.
TIBCO ActiveMatrix BusinessWorks Service Engine
TIBCO ActiveMatrix BusinessWorks Service Engine is a gateway for TIBCO ActiveMatrix BusinessWorks to the Service Oriented Architecture (SOA) world. The product provides an ActiveMatrix container to deploy ActiveMatrix BusinessWorks projects using TIBCO ActiveMatrix Administrator. The TIBCO ActiveMatrix BusinessWorks and the TIBCO ActiveMatrix BusinessWorks Service Engine provide enhanced service orchestration in the ActiveMatrix environment. This product installs the ActiveMatrix BusinessWorks container where you can deploy and run an ActiveMatrix BusinessWorks project in the ActiveMatrix environment.
The main features of the ActiveMatrix BusinessWorks Service Engine are,
1. Provide Services to Other ActiveMatrix Components
ActiveMatrix BusinessWorks Service Engine allows other ActiveMatrix
Components to discover and invoke ActiveMatrix BusinessWorks services. In
Order to provide services to other ActiveMatrix components, ensure that the
ActiveMatrix BusinessWorks project with Service resources is available. Other ActiveMatrix components can invoke these services based on the PortTypes exposed by these service resources.
2. Consume Services Provided by Other ActiveMatrix Components
ActiveMatrix BusinessWorks Service Engine allows ActiveMatrix BusinessWorks to consume services provided by other components in the ActiveMatrix platform.
In order to consume services provided by ActiveMatrix components, the
ActiveMatrix BusinessWorks project with partner definitions should be available. Also, a Partner WSDL for the ActiveMatrix service should be available. If you are to consume an external service through SOAP Reference, concrete WSDL of the service should be available.
3. Manage Life Cycle of Standalone ActiveMatrix BusinessWorks Projects
You can deploy and run a standalone ActiveMatrix BusinessWorks project in the ActiveMatrix platform. By doing so, you can benefit from a single deployment and life cycle management of the components using the ActiveMatrix Administrator.
TIBCO ActiveMatrix Administrator
TIBCO ActiveMatrix Administrator is the utility used to create, configure, manage, and monitor various objects in the ActiveMatrix runtime. These objects include enterprise assets, environments, machines, nodes, shared resources, containers, service assemblies, service units, and services.
TIBCO ActiveMatrix Administrator consists of the following components
1) ActiveMatrix Administrator Server Gathers management data from nodes, responds to requests from the ActiveMatrix Administrator graphical and command-line UIs, interacts with the authentication realm to authenticate users, and interacts with TIBCO Management Daemon to manage nodes.
2) ActiveMatrix Administrator Cluster Groups one or more ActiveMatrix Administrator servers. ActiveMatrix Administrator servers within a cluster share a database and authentication realm and are kept synchronized.
3) ActiveMatrix Database Stores ActiveMatrix administration data.
4) ActiveMatrix Administrator Graphical UI Provides a graphical user interface.
5) ActiveMatrix Administrator Command-Line Interface Provides a script-based interface
6) ActiveMatrix Administrator Command-Line Interface Provides a script-based interface.
7) Management Daemon Gathers installation information and exposes ActiveMatrix node life cycle operations
Deploying to a Business Works Service Container
There are three ’locations’ or ‘containers’ that a Business Work EAR can be deployed to. These are:
1) Business Work Standalone Service Engine
2) Business Work Service Engine Implementation Type (BWSE-IT) within an ActiveMatrix Node
3) Business Work Service Container (BW-SC)
The first two scenarios do not require any special effort during deployment and usually can be done through the admin interfaces (bw-admin for standalone and amx-admin for BWSE-IT). But if one wishes to deploy an EAR to a Service Container then we need to setup the container and make a change in the Process Archive. This tutorial is for a Windows-based system.
Before we get into all that let us figure out what a BW Service Container (BW-SC) and why one would want to use it.
A BW-SC is a virtual machine which can host multiple processes and services within individual process engines. Each EAR deployed to a BW-SC gets its own process engine. The number of such process engines that can be hosted by a container depends on the running processes and the deployment configurations. To give an analogy, the load that an electric supply (service container) can take depends on not just the number of devices (i.e. process engines) on it but also how electricity each device requires (processes running within each engine).
Keeping in mind the above, when using BW-SC, it becomes even more important to have proper grouping of processes and services within an EAR.
The standard scenario when you would use a BW-SC is for fault-tolerance and load-balancing. In other words, to deploy the same service (fault-tolerance) and required backend processes (load balancing) on multiple containers. Also Service Containers can be used to group related services together to create a fire-break for a failure-cascade.
The first step to deploying to a BW-SC is to enable the hosting of process engines in a container. The change has to be made in the bwengine.xml file found in the bw/<version>/bin directory. Locate the following entry (or add it if you cannot find it):
<property>
<name>BW Service Container</name>
<option>bw.container.service</option>
<default></default>
<description>Enables BW engine to be hosted within a container</description>
</property>
<name>BW Service Container</name>
<option>bw.container.service</option>
<default></default>
<description>Enables BW engine to be hosted within a container</description>
</property>
The second step is to start a service container to which we can deploy our EARs. Go to the command line and drill down to the bw/<version>/bin directory. There run the following command:
bwcontainer –deploy <Container Name>
Here the <Container Name> value, supplied by you, will uniquely identify the container when deploying EARs. Make sure that the container name is recorded properly. In the image below you can see an example of starting a container called Tibco_C1.
The third step is to deploy our application to the container (Tibco_C1). Log in to the BusinessWork Administrator and upload the application EAR. In the image below the test application EAR has been uploaded and awaits deployment.
The fourth step is to point the process archive towards the container we want to deploy to. Click on the Process Archive.par and select the ‘Advanced’ tab. Go down the variable list and locate the bw.container.service variable which should be blank if you are already not deploying to a container.
Type the container name EXACTLY as it was defined during startup. TIBCO will NOT validate the container name so if you set the wrong name you will NOT get a warning, you will just be left scratching your head as to why it didn’t work. In our example we enter ‘Tibco_C1′ in the box (see below).
Save the variable value and click on Deploy. Once the application has been deployed, start the service instance. That is it.
To verify that your application is running on the container, once the service instances enter the ‘Running’ state, go back to the command line and the bin directory containing bwcontainer.exe. There execute the following:
bwcontainer –list
This command will list the process engines running in any active containers on the local machine. The output from our example can be seen below.
We can see the process archive we just deployed, running in the Tibco_C1 container.
If you have any other containers they will also show up in the output.
Remember one important point: If a service container goes down, all the deployed applications also go down. These applications have to be re-started manually through the Administrator, after the container has been re-started.
