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>
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.
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>
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.
For training on TIBCO BusinessWorks mail us at [email protected]
RSS Feed
