Researched and written by Xmarter TIBCO Consultants
Traditional deployment of business integration project requires a lot of configuration effort. The administrator needs to ensure that the configurations for multiple interactions are supported and configuration files are required for different components on different machines. TIBCO ActiveMatrix BusinessWorks, in contrast, provides an interface for creating deployment configuration and then deploying the project. To deploy TIBCO ActiveMatrix BusinessWorks Projects, TIBCO Administrator is used. It is a central administrator server for creating, deploying, managing, and monitoring TIBCO applications and machines within the administration domain. Upon deployment, TIBCO Administrator will create deployment configuration that will be sent to the machines where the projects will be deployed.
All TIBCO BusinessWorks Projects undergo same project phase: design, deploy, and run. After designing and testing the process in TIBCO Designer and setting up the required resources, projects will be deployed in TIBCO Administrator to run on its designated machines. There are two ways to deploy the project in the TIBCO Administrator Server: using the TIBCO Administrator GUI or using scripting deployment utilities. TIBCO Administrator GUI is a web-based graphical-user interface where administrators can easily manage and deploy TIBCO BusinessWorks Projects using a web browser while scripting utilities allow TIBCO Administrator functions to be executed from the command-line.
In using TIBCO Administrator GUI to deploy projects, an Enterprise Archive (EAR) file needs to be created using TIBCO Designer. The EAR file must contain all the required resources such as adapter configurations and process definitions that need to be deployed. After building the EAR file, it will be uploaded to TIBCO Administrator GUI to create the application and to set deployment configuration. On the other hand, in using command-line utilities for deployment, only the Buildear and AppManage utilities are used. Buildear utility is used to build the EAR file based on an archive defined in a TIBCO Designer project while AppManage utility creates an XML based deployment configuration file then uploads the deployment file and EAR file into TIBCO Administrator.
TIBCO Administrator allows applications to be deployed multiple times. However, only one deployment configuration can run anytime. It has a Configuration Console which provides options for deploying and updating applications and it maintains a deployment configuration history that allows reverting of deployments in the future. Updating of application is very important if new TIBCO software is installed on the machines where the application is deployed.
Once an application is deployed, TIBCO Administrator imports all the values defined for global variables from the EAR file. This allows global variables to be changed during deployment. Global variables may vary depending on the environment and these variables might use environment specific values. Thus, setting correct variables during deployment is critical for the application to run.
TIBCO Administrator enables administrator to manage deployed processes and services included in the application. Processes deployed in TIBCO Administrator can be assigned and run on any machine that belongs to the same administration domain. The target machine where processes and services are deployed is called ‘container’. Services can also be enabled and disabled. Disabled services will not be deployed in the next application deployment unless enabled before deploying. Service’s process instances execution can be controlled by changing process configuration properties like Max Jobs, Activation Limit and Flow Limit. This is helpful if process instances need to run sequentially due to limited CPU resources and memory. Max Jobs property is used to limit the number of concurrent process instances that can be loaded in memory. Meanwhile, Activation Limit property is selected if process instances that are loaded in memory will stay in memory until completion. However, Flow Limit property sets the maximum number of process instance that can be started before suspending the process starter.
Project deployment maybe a simple task but it’s at least as important as the project design. Deployment needed to include required resources and configurations to have a smooth run in production. Thus, TIBCO ActiveMatrix BusinessWorks allows business integration project deployment to be easily configured and run on any machine in the domain.
In another perspective, TIBCO lets you integrate different incompatible applications in a service-oriented architecture (SOA). This can be achieved through ActiveMatrix (AMX) Service Grid and other AMX family of products. In AMX Service Grid, you can create a composite, which contains services, components, and references. You can think of a composite as a circuit board which holds several important electronic modules.
Services simply refers to web services, which are standardized methods of communication between two contracting parties, commonly a service provider and a service consumer/client, in a language only both of them can understand. Communication happens through message exchanges either one-way or two-way. In a two-way communication, the consumer sends a request message and expects a response message back. This message comes in a specific format usually SOAP or JMS.
Components are implementations of web services. You can use TIBCO ActiveMatrix BusinessWorks, Java, .NET, or Ruby to create the implementations of web services provided that these applications conform to the specifications that describe your web services. A common model used to describe the specifications of web services is the Web Services Definition Language (WSDL). However, there are circumstances when the service provider or the implementing applications cannot change the structure of the message format they are using, yet the client must conform to their specification. This is where mediation comes in. One of the things mediation does is translating the message into a format which can be understood by the receiving end.
References are external web services which provide operations you want to reuse as implementations of your own web services. Alternatively, you can refer to another composite within your AMX SOA project.
After creating the composite, you need to be able to run the web service by deploying it to logical and physical servers. Now that you have pieced all the components together in the circuit board, you need to make sure that these components will work harmoniously as a single unit. Deploying web services in AMX Administrator, which supports both graphical and command-line interfaces, is very simple and straightforward and takes less time to achieve.
First, you need to create a service assembly. A service assembly is simply a collection of composite, shared resources, connections, metadata, and other necessary files in your AMX SOA project. Think of it as a CPU composed of a motherboard, which is like a composite, together with other essential stuffs, to make the whole system working. The service assembly is compressed into a portable ZIP file which is uploaded to AMX Administrator GUI during deployment. You can create a service assembly by using a utility provided in TIBCO Business Studio, which is the main development tool for creating AMX SOA projects.
When you upload the ZIP file, AMX Administrator will automatically determine what components are present and are ready to be deployed in nodes. Nodes are instances of the Java Virtual Machine, which run containers, software that executes the code, and the messaging bus. Nodes are installed on a physical server and they can be started, stopped, and uninstalled anytime, while containers can either be activated or deactivated. You can deploy various components, which become service units during runtime, into multiple nodes for fault tolerance and load balancing. You can map several nodes to one service unit.
The environment lets you logically manage the nodes, the messaging bus, which can be one or more instances of the TIBCO Enterprise Message Service, and the connectors, containers, shared resources, and keystores contained in nodes. Shared resources enable services to connect with physical resources such as a JMS or an HTTP server. You can have one or more environments to enable and maintain system scalability and flexibility depending on system requirements. Environments also let you configure logging events for tracing errors easily and manage substitution variables or enterprise level variables which could potentially alter from one environment to another. Examples of these variables are queue destinations, service URLs, among others.
When it meets all the requirements for deployment, the service assembly now becomes deployable. On AMX Administrator, you can just simply click the Deploy button to deploy the service and after it is deployed, you can start the service. When the status changes to Running, your web service is now usable and ready to accept requests from service clients.
AMX Administrator GUI comes with monitoring and management tools such as dashboard, infrastructure, service, deployment, and log views which let you track the status, health, and performance of the AMX infrastructure and the services running on that infrastructure.
AMX Administrator also provides a utility that gives you an option to deploy services through the command-line interface. All you have to do is write build scripts which are in XML format and specify the deployment options with the target resources you want to execute. Scripting makes it easier and faster to deploy services especially if it requires you to deploy a lot of services into multiple nodes and environments. It also makes deployment possible for operating systems that don’t support GUI.
TIBCO ActiveMatrix simplifies the life cycle of web services and empowers you truly create SOA applications easily, rapidly and efficiently. With the accelerating adoption of SOA in enterprise applications, you can be assured that your business will realistically benefit in the long run from using this software. With absolutely shorter integration phases and quicker, zero downtime deployments, the TIBCO ActiveMatrix solution strongly brings business advantage and growth together to a much higher level.
|In this TIBCO video, you will learn about the different software products in the TIBCO BusinessEvents 4.0 suite. Unlike the TIBCO BusinessEvents 3.0 Enterprise Edition, the 4.0 version consists of numerous smaller software products. You pick and choose which product to use for your unique Complex Event Processing requirements.|
If you want an event to inherit the properties of another event, it is critical that neither events have properties with the same name. For example, if both EventA and EventB have a property called “Name”, then these events cannot be made to inherit the other.