To following my previous post about EMS Central Administration installation, this part is about client.

There is the same Universal Installer by TIBCO, it helps to make installation process easy. Execute it, accept the license agreement, create a new or select an existing environment, check the summary and complete the installation.

Then I can star EMSCA from my Start menu. This is Eclipse, I have to create a new workspace. Then File => New EMS Central Administration Project. Enter host name and port, where is EMSCA Server is installed. Enter username and password to connect, select the deployment to create a project for.

Next step is synchronizing with EMS. TIBCO EMS => Synchronize Configurations With EMS Servers. Enter username and password, select EMS server to synchronize.

Now I can change the server configuration. Then save to SVN repository. TIBCO EMS => Save Configurations to Repository.

Then it is possible to deploy changes to the server. TIBCO EMS => Deploy EMS Project.

So, this was short description of the TIBCO EMS Central Administration, very helpful tool to manage configurations of multiple EMS instances.

I’d like to share my experience about installation of the TIBCO Enterprise Message Service Central Administration (EMSCA) server and client. At this time, TIBCO provides EMSCA server software only for Linux (Red Hat Enterprise Linux 4 and 5 (x86), Oracle Enterprise Linux 4 and 5 (x86) and SUSE Enterprise 10 (x86)) and EMSCA client only for Windows, but as client is Eclipse based, I think that it could be ported easily.

I will start with the server side installation on my Red Hat Linux. The new TIBCO Universal Installer can run in GUI (default), console or silent mode. If you prefer GUI, don’t forget to set DISPLAY:
LOGINFROM=`who am i | cut -f2 -d"(" | cut -f1 -d")"`
DISPLAY=${LOGINFROM}:0.0
export LOGINFROM DISPLAY

Run the installer # ./TIBCOUniversalInstaller-lnx-x86.bin, accept the license agreement, create a new or select an existing environment. Installation will perform quickly. When installation is complete, it is necessary to do some post installation tasks:

• Environment variables from the file <emsca_home>/1.0/bin/setenv must be set. Perhaps it is good idea to call this file from the user’s profile or add content of this file to the profile;
• Make Apache run as the user ‘nobody’:
  # cd <emsca_home>/1.0/httpd/conf
# vi httpd.conf
User nobody
Group nobody
  and make sure that user and group ‘nobody’ are in the system;
• Configure an authentication in Apache:
  # vi httpd.conf
AuthBasicProvider file
AuthUserFile conf/users.txt
  Then prepare users file, I will define the ‘admin’ user only:
  # cd ../bin
# ./htpasswd -c ../conf/users.txt admin
New password:
Re-type new password:
Adding password for user admin
  Then check the file:
  # cd ../conf/
# cat users.txt
admin:GfwLuEIw320SY
• Adding Subversion users and change folders owners:
  # cd /opt/tibco/ems/ca/1.0/repos/conf
# cat pre-commit.perms
admin
  So, ‘admin’ is already here. Next check/set owner for the repos and temp Subversion’s folders:
  # pwd
/opt/tibco/ems/ca/1.0
# chown -R nobody:nobody repos temp
  Owner should be the same user as running apache (‘nobody’ in my case).

Then I can start emsca:
# emsca start
Starting TIBCO EMS Central Administration
Started Apache httpd: pid=20119
Started Tomcat: pid=20140

and check Apache logs in the <emsca_home>/1.0/httpd/logs folder.

Next step is to create a new deployment server. Deployment server is one per project, can be one for many EMS.
# emsca server create rhl01
Created directory 'rhl01' in the repository
Created directory /opt/tibco/ems/ca/1.0/servers/rhl01
Created configuration file '/opt/tibco/ems/ca/1.0/servers/rhl01/conf/configuration.xml'
Created deployment server 'rhl01'

Now creating a new central administration agent. One agent per one EMS.
# emsca agent create rhl01 name=agent_EMS-SERVER1 path=/ems-server1.emsserver url=tcp://10.2.148.82:7222
Created agent on deployment server 'rhl01'

It is possible to provide a username and a password to connect to the EMS. If is not included, the agent uses ‘admin’ ad username and an empty password. ems-server-username – the username used to connect to the tibemsd, ems-server-password – used with ems-server-username to connect to the tibemsd. Also it has options to grant agent some additional rights, find in the docs.

To check EMSCA server use:
# emsca list
TIBCO EMS Central Administration
Deployment Servers
------------------
rhl01 (started)

# emsca status
TIBCO EMS Central Administration Status
Apache httpd is running: pid=1427
Tomcat is running: pid=1448

In the next post I will describe the client part installation and configuration.

TIBCO Enterprise Message Service 6.0 has been released in July 2010.
Some new features:

• mstore – new message store type, which designed for quick EMS recover after failover;
• new parameters for incoming message size, swapping and redelivery delay;
• cursoring through topics and queues lists in tibemsadmin tool;
• new startup script to quickly start with default configuration;
• host id and message size now included in message tracing;
• new methods in APIs for failover notification and message recovery.

This release requires database schema update when migrating database store from EMS version 5.x.

HermesJMS provides a GUI to access JMS queues and topics for common tasks such as sending messages, removing messages and copying messages between queues and topics. It’s one of some “must have” tools for EMS admins and application support team.

Get the latest installer from SourceForge: http://sourceforge.net/projects/hermesjms/files/ then run it:
java -jar hermes-installer.jar

Installation is very simple, just few screens: release notes, license agreement, installation path, components (here is only one actually), summary, files copying, shortcuts creation and installation finish.

To start HermesJMS run hermes.bat in your <installation_folder>\HermesJMS\bin. If you got error message “cannot find \bin\javaw”, make sure that you have JAVA_HOME system variable defined to your jre folder.

When Hermes started successfully, click on “Create new JMS session” button, preferences window will appear, select providers tab and right-clik on free space. Then press “Add Group” and enter group name. Right-click on “Library” and press “Add JAR(s)”. Look in <tibco_home>\ems\5.1\lib folder and select all .jar files there. Click “Open”, then let Hermes to scan jars for factories: press “Scan” button. Then press “Apply”. All libraries will be in the list like on my screenshot.

Go to “Sessions” tab and enter name for session: “My EMS” for example, then select “EMS” loader. Next step is select “com.tibco.tibjms. TibjmsConnectionFactory” class and “Tibco EMS” plugin. Order is very important: select loader, then class, then plugin. Right-click on free space in plugin section and press “Add property”. You have to enter all three properties: username, password and serverURL, do the same for Connection Factory, then press “OK” to save and close properties window.

Now we can connect Hermes to our EMS. Let it discover queues and topics, press “Discover queues and topics from the provider” button. Then confirm replacement of the current set of destinations and list will be updated. That’s all.

If you need more information: HermesJMS home.

If the EMS admin password has been lost, it is easy to recover. In EMS all local users and their passwords stored in the users.conf file by default. You can find correct file in the tibemsd.conf:
users = "C:/tibco/tibco/cfgmgmt/ems/data/users.conf"

In the users.conf find admin user:
admin:$2$Z1t2XOwg$vsDsUT+GVRHRiX+OPU/oOsn0:"Administrator"
and remove encrypted password between colons:
admin::"Administrator"

Then restart EMS daemon. Connect to your EMS using EMS Administration Tool and login as admin without password:
> connect
Login name (admin):
Password:
Connected to: tcp://localhost:7222

Then set a new password for admin:
tcp://localhost:7222> set password admin 123
Password of user 'admin' has been modified

If you manage EMS in the TIBCO Administrator, then you need to change EMS admin password there. Start TIBCO DomainUtility, select “TIBCO EMS Plugin”, “Update TIBCO EMS Server”, press “Next”. Select domain and enter domain (not EMS!) admin user name and password. Select EMS server to update, and change EMS password there, test connection on the next screen and press “Next” to save new configuration.

So, EMS password recovery is very simple, isn’t it?

Remark: this is a brief overview from the admin perspective. If you ask a developer or architect, then their views may differ greatly from what you find below :)

TIBCO Enterprise Message Service (EMS) is fully compliant Java Message Service (JMS) implementation from TIBCO with some enterprise-class enhancements. What is it? In general, from JMS FAQ:

The Java Message Service makes it easy to write business applications that asynchronously send and receive critical business data and events.

The Java Message Service defines a common enterprise messaging API that is designed to be easily and efficiently supported by a wide range of enterprise messaging products.

The Java Message Service supports both message queuing and publish-subscribe styles of messaging (topics).

It is main part of Enterprise Backbone, Enterprise Middleware and Enterprise SOA. Unlike TIBCO Rendezvous, where publishers and subscribers communicate directly without server, EMS represent dedicated server, hub which connects all clients and passes through itself all messages.

Better to see once than hear a hundred times. Installation process for EMS server is very simple, I slightly described installation on Windows platform in this post. On Solaris or other *nix we can run installer with [-console] option if X11 isn’t configured:
bash-3.2# ./TIBCOUniversalInstaller-sol-sparc.bin -console

New TIBCO Universal Installer will store configuration files and message storages separately from binaries and allows to have multiple environments on the same host, you must specify both paths. EMS is not required any additional components like TIBCO Runtime Agent (TRA), everything is included in the archive.

To start EMS manually with output to console, just execute tibemsd or tibemsd64 (depend on platform) with option [-config] and path to tibemsd.conf file. Later in production it will run as a system service on Windows (install or remove service using emsntsrg utility) or as a daemon in Unix. Start process from console is also good for debugging purposes, if an error somewhere in the configuration files and service isn’t running.

All EMS configuration stored in the configuration files and these files are read when the EMS process going up. Main file is tibemsd.conf: it’s contain service name, listening TCP port, links to other configuration files, logging options and etc. If start EMS without specifying tibemsd.conf file, it will try to find it near binary, if unsuccessful then conf files will be created near binary with default values.

The most of EMS configuration, like new user, new queue or bridge, performed using administration tools on the live system and become active immediately, no restart required. Then changes saved in the corresponding conf files to be restored when you restart the service. But it is also possible to modify conf files manually. Moreover, some parameters, like message storages location or log file name must be predefined in conf files and EMS restart is necessary. Before each change make sure to have fresh backup of the configuration files!

For EMS administration tasks some tools are available: tibemsadmin – command line administration tool provided with EMS, EMS plugin for TIBCO Administrator, Gems (Graphical Administration Tool for EMS) by Richard Lawrence, HermesJMS. Using these tools admin can manage topics, queues, bridges, users and so on. For monitoring EMS offers many options for logging and trace. Also, admin can subscribe to system topics beginning with “$sys.monitor.” for live evens monitoring (easiest using tibemsmonitor utility).

Files used to store messages will be created on the first start using parameters in the stores.conf file (before version 5 in tibemsd.conf). In the normal operational mode, messages may accumulate in the topics and queues if no recipients – files will grow when needed, and therefore it is necessary to continuously monitor, otherwise the service may become unusable. It is possible to predefine minimal size of those files, it will take some time to build files for the first time if predefined size is large, but help to avoid fragmentation. Shrink or truncate large files to predefined minimum is also possible. When EMS restarts, all persistent messages will be recovered, but it will take some time to recover if files are large. In general, when you upgrade EMS from 4.x to 5.x, all stores will be upgraded automatically. Downgrade or rollback is also possible using tibemsdb5revert.

To provide high availability, two EMS servers can run as active-standby fault-tolerant pair. The main requirement of this configuration is the simultaneous access to store files – Cluster File System is required. Veritas Storage Foundation Cluster File System as expensive enterprise solution example. Some variants with network shares or NFS are also possible but guaranteed uptime and messages rate can be much lower. Alternative approach – failover cluster with shared volume.

Starting with EMS version 5 it became possible to use a database to store the messages. This simplifies the creation of fault-tolerant pair – no need to create a shared file system, enough to configure two servers to the same database. So far I haven’t collected a sufficient pro and cons, if you have such please share in the comments.

And lastly few words about connecting clients. Usually, when your application must be integrated into TIBCO middleware, means that you need communicate to EMS only. The most of SOA oriented applications are ready to communicate with JMS, Java clients can use JMS classes. TIBCO ActiveMatrix BusinessWorks has JMS palletes. Applications must be able to work with the fault-tolerant pair of two servers, provide reconnection in case of connection failure, support authentication.

Useful links:

• EMS Community
• JMS Tutorial from SUN

Here is the article on Symantec site. I can agree that installing TIBCO Enterprise Message Service (EMS) on Veritas Storage Foundation Cluster File System (CFS) is the best high availability and high performance solution. If your company really need 99.999% uptime, 50000 messages per second and ready to pay much for that.

Whenever we need to choose the most suitable solution, we must consider the various options. For example, if the SLA is required to ensure very high uptime, but not expected tens of thousands of messages per second, you can consider EMS options using NFS or HA Database for messages store. In the opposite case can be encouraged to use the failover cluster with shared cluster disk.