What is TIBCO EMS?

by Serge in EMS
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 Iully compliant Java Message Service
(JMS) implementation Irom TIBCO with some enterprise-class enhancements.
What is it? In general, Irom 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 deIines a common enterprise messaging API that is
designed to be easily and eIIiciently supported by a wide range oI enterprise
messaging products.
The Java Message Service supports both message queuing and publish-subscribe
styles oI messaging (topics).
It is main part oI 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 itselI all messages.
Better to see once than hear a hundred times. Installation process Ior EMS server is
very simple, I slightly described installation on Windows platIorm in this post. On
Solaris or other *nix we can run installer with |-console| option iI X11 isn`t
conIigured:
bash-3.2# ./TIBCJUniversalInstaller-sol-sparc.bin -console
New TIBCO Universal Installer will store conIiguration Iiles and message storages
separately Irom binaries and allows to have multiple environments on the same host,
you must speciIy 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 platIorm) with option |-conIig| and path to tibemsd.conf Iile.
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 Irom console is also good Ior debugging purposes, iI an
error somewhere in the conIiguration Iiles and service isn`t running.
All EMS conIiguration stored in the conIiguration Iiles and these Iiles are read when
the EMS process going up. Main Iile is tibemsd.conf: it`s contain service name,
listening TCP port, links to other conIiguration Iiles, logging options and etc.
II start EMS without speciIying
tibemsd.conf Iile, it will try to Iind it near binary, iI unsuccessIul then conI Iiles will
be created near binary with deIault values.
The most oI EMS conIiguration, like new user, new queue or bridge, perIormed using
administration tools on the live system and become active immediately, no restart
required. Then changes saved in the corresponding conI Iiles to be restored when you
restart the service. But it is also possible to modiIy conI Iiles manually. Moreover,
some parameters, like message storages location or log Iile name must be predeIined
in conI Iiles and EMS restart is necessary. BeIore each change make sure to have
Iresh backup oI the conIiguration Iiles!
For EMS administration tasks some tools are available:
tibemsadmin command line
administration tool provided with EMS, EMS plugin Ior TIBCO Administrator, Gems
(Graphical Administration Tool Ior EMS) by Richard Lawrence, HermesJMS.
Using these tools admin can manage
topics, queues, bridges, users and so on. For monitoring EMS oIIers many options Ior
logging and trace. Also, admin can subscribe to system topics beginning with
'$sys.monitor. Ior live evens monitoring (easiest using tibemsmonitor utility).
Files used to store messages will be created on the Iirst start using parameters in the
stores.conf Iile (beIore version 5 in tibemsd.conf). In the normal operational mode,
messages may accumulate in the topics and queues iI no recipients Iiles will grow
when needed, and thereIore it is necessary to continuously monitor, otherwise the
service may become unusable. It is possible to predeIine minimal size oI those Iiles, it
will take some time to build Iiles Ior the Iirst time iI predeIined size is large, but help
to avoid Iragmentation. Shrink or truncate large Iiles to predeIined minimum is also
possible. When EMS restarts, all persistent messages will be recovered, but it will
take some time to recover iI Iiles are large. In general, when you upgrade EMS Irom
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 Iault-tolerant
pair. The main requirement oI this conIiguration is the simultaneous access to store
Iiles 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 Iailover cluster with shared volume.
Starting with EMS version 5 it became possible to use a database to store the
messages. This simpliIies the creation oI Iault-tolerant pair no need to create a
shared Iile system, enough to conIigure two servers to the same database. So Iar I
haven`t collected a suIIicient pro and cons, iI you have such please share in the
comments.
And lastly Iew words about connecting
clients. Usually, when your application must be integrated into TIBCO middleware,
means that you need communicate to EMS only. The most oI 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 Iault-tolerant pair oI two servers, provide reconnection in case oI
connection Iailure, support authentication.