Enterprise Message Service Architecture

 TIBCO Enterprise Message Service is a standards-based messaging solution that supports the implementation of
a Service-Oriented Architecture by providing Java Message Service (JMS) compliant communications across a
wide range of platforms and application technologies.
 It uses a hub-and-spoke architecture. A hub-and-spoke architecture provides a central intermediary (called a hub)
through which applications communicate with each other.
 In this architecture, each application (which represents a spoke) communicates with the intermediary (the hub),
which in turn manages communication with the other applications. Applications do not communicate directly
with each other.
 Enterprise Message Service integrates support for connecting other TIBCO message services, such as TIBCO
FTL, TIBCO Rendezvous, and TIBCO SmartSocket. It uses C based server process for optimum performance
and is fully compliant with the Oracle JMS versions 1.1 and 2.0.

Administration Options
The slide shows various options available for Enterprise Message Service administration:

 EMS Administration Utility uses command-line interface.

 TIBCO Administrator, a separate TIBCO product that uses Web-based Graphical User Interface.
 EMS Central Administrator, a tool for centralized administration and deployment of multiple Enterprise Message
Service servers.
 Custom Interface using API like Java or .Net.
 TIBCO Hawk® Micro agent enables to monitor Enterprise Message Service applications using TIBCO Hawk in
enterprise environments.

Tibemsd.conf File
 The main configuration file that controls the characteristics of TIBCO Enterprise Message Service server
is tibemsd.conf.
 It contains many general configuration parameters, like, server name, password, listen port, message storage
location, memory parameters etc.
 It also refers to other configuration files containing the additional parameters. Additionally, this file also contains
other parameters like fault tolerance, SSL server, LDAP etc.
 You can update configuration files using administration tools listed in the previous slide, or by editing them
directly via text editor. Configuration changes done by administration tools have immediate effect, while changes
done by editing becomes active only after you restart the EMS server.
 A few configuration items can only be altered by editing. Use caution when you edit configuration files directly -
an error in configuration may prevent the server from starting.

factories.conf File
 Factories.conf file defines the connection factories stored as Java Naming and Directory Interface (JNDI) names
on the Enterprise Message Service server.
 The file format is as shown in the slide.
 The mandatory parameters are factory name i.e. the name of the connection factory, type of the connection
factory, and url, that specifies the servers to which this factory creates connections.
 Other parameters like clientID, ssl-prop etc. are optional.
  An example of configured factories.conf file is as shown on the slide. Tibemsadmin tool is used to configure
connection factories in the file using the command ‘createfactory’

Users.conf and Groups.conf Files

 Users.conf file defines all the users.
 The format of the file is as shown on the slide. Username : password : description.
o Passwords are not entered in the configuration file but are set using administration tool or API calls.
 Note: On the TIBCO Administrator Tool command create user, the description must be specified before the
password, otherwise it is ignored.
 Groups.conf file defines all Enterprise Message Service groups. The format of the files is as given in the slide.
Administration tool command create group is used to create groups.

Topics.conf and Queues.conf Files

 Topics.conf file defines all the topics.
 The format of the file is shown in the slide.
 Administration tool is also used to create topics and command for the same is shown.
 Only topics listed in this file or topics with names that match the topics listed in this file can be created by the
applications.
 For example, if topic foo.* is listed in this file, topics foo.new and foo.bar can be created by the application.
 Properties of the topic are inherited by all static and dynamic topics with matching names. For example, if test.*
has the property secure, then test.1 and test.jms are also secure.
 Queues.conf file defines all the queues. The format used in the file and admin tool command to create queue is
shown in the slide. Only queues listed in this file can be created by the applications.
 For example, if queue foo.* is listed in this file, queues foo.new and foo.bar can be created by the application.
 Properties of the queue are inherited by all static and dynamic queues with matching names.

set and Enable Access Control

Steps to set and enable access control are as follows:

 Enable global access control for the system by enabling authorization. The authorization is enabled either by
editing the configuration file tibemsd.conf or by using the administration tool.
 Enable access control for the destinations. Determine which destinations require access control and enable access
control for those destinations by setting destination properties in the topics.conf or queues.conf file. You can
also set these properties by using the administration tool.
 Determine users who need administration permissions and grant the administrator permissions to the selected
users in the acl.conf file.
 Determine the names of the authorized users of the system and create usernames and passwords for these users.
 Create the access control list by granting specific permissions to the users (or groups) for destinations that need
to be secure.

Users, Groups and Permissions

 TIBCO Enterprise Message Service allows you to create users and assign passwords to the users to control
access to the EMS server.
 You can also assign permissions to users and groups to control actions that can be performed on destinations.
  Permissions apply to the activities a user can perform on each destination (topic and queue).
 Using permissions you can control which users have permission to send, receive, or browse messages for
queues.
 You can also control who can publish or subscribe to topics, or who can create durable subscriptions to topics.
Permissions are stored in the access control list for the server. Groups create classes of users and control
permissions on a more global level.
 You can control destination access at the group level.
 Users inherit any permissions from each of the groups they belong to, in addition to any permissions that are
granted to them directly.

Acl.conf File
 Access control list file defines all the permissions on topics and queues for all users and groups.
 The image at top-right of the slide shows the file format and the image at bottom-right shows an example of
configured acl.conf file.
 Administration tool command grant can also be used to provide permissions to specified user or groups on
specified topic or queue.

Administration Tool
 The Enterprise Message Service Administration Tool is located in EMS_HOME/bin directory and is a stand-
alone executable named tibems admin on UNIX and tibemsadmin.exe on Windows platforms. The Enterprise
Message Service server instance must be running before you start the Administration Tool.
 Type tibemsadmin -help to display information about tibemsadmin startup parameters.
 Enter help for a summary of all available commands. Enter help command for help on a specific command.
 For example: help remove command gives command description and syntax to remove users from a group.
 The command line interface of the administration tool allows you to perform a variety of administrative
functions, like, grant permission, add/remove users and groups, etc. After all the tasks are performed you can
disconnect the tool and exit from the server.

Lab

In this exercise, gain basic familiarity with the Enterprise Message Service™ Administration Tool, such as,
use the help feature, connect to the server, create new users, create a group, assign users to a group, and create
destinations.

#Command to start EMS server

cd /home/tibco/Scripts
./start-ems-server.sh

#Command to start Administration tool and connect to server

cd /opt/tibco/ems/8.5/bin
tibemsadmin
connect

#Command to create three new users

create user CHATMAN password=CHATMAN
create user CHATWOMAN password=CHATWOMAN
create user CANTCHATMAN password=CANTCHATMAN

#Command to add users to group

add member TALKERS CHATMAN
add member TALKERS CHATWOMAN

Explore Enterprise Message Service™ Access Control

In this exercise, run a simple JMS client program to explore TIBCO Enterprise Message Service server administrative
features such as users, security and groups. Chat.java is a simple JMS program that accepts a topic name, user name and
password as parameters. It uses the user name and password to authenticate the user when connecting to the TIBCO
Enterprise Message Service server. The program publishes and subscribes to messages on the topic passed in as a
parameter. The syntax to run this program is as follows:

java Chat <topic_name> <user_name> <password>

Note: The required Chat.java file is available in the Lab_Files/Solution directory. You can download this file from
Pre-course Information lesson.
#Command to compile java sample programs
cd /opt/tibco/ems/8.5/samples/java
source setup.sh
javac *.java
ls *.class

#Command to run Chat program as the CHATWOMAN user

source setup.sh
java Chat TESTCHAT CHATWOMAN CHATWOMAN

#Command torun Chat program as the CHATMAN user

source setup.sh
java Chat TESTCHAT CHATMAN CHATMAN

#Command torun Chat program as the CANTCHATMAN user

source setup.sh
java Chat TESTCHAT CANTCHATMAN CANTCHATMAN

#Command to edit Chat.java file

sudo gedit Chat.java
password: TIBCO7222

#Command to grant the TALKERS group permission to publish and subscribe on the
TESTCHAT topic
grant topic TESTCHAT TALKERS publish,subscribe

#Command to set the properties of the TESTCHAT topic to secure

addprop topic TESTCHAT secure

#Command to to enable authorization

set server authorization=enabled

#Backup config files

sudo cp /opt/tibco/ems/8.5/samples/config/*.conf
/home/tibco/Lab_Files/Export/LabA
password:TIBCO7222

Enterprise Message Service™ User Management and

SSL
Inheritance via Wildcards
Enterprise Message Service supports wildcard notation:

 You can use wildcards when specifying statically created destinations in queues.conf and topics.conf. The use of
wildcards in destination names is used to define parent and child destination relationships, where the child
destinations inherit the properties and permissions from its parents.
 You can subscribe to wildcard topics, but not publish to them. You cannot send or receive to wildcard queue
names.
 Two wild card patterns are used:
o * (asterisk) means any token can be in the place of *.
o > (greater than) matches one or more trailing elements.
 Inheritance of Properties: All destination properties are inheritable for both topics and queues. This means that a
property set for a wildcarded destination is inherited by all destinations with matching names. For example, if the
topic TIBCO.* is failsafe, then the topics TIBCO.CHOC and TIBCO.boo will also be failsafe. Removal of
inherited properties is not supported.

The following property does not comply with the inheritance rules:

The maxbytes property (used for both queues and topics) can be overridden by the topic or queue instance that would
normally inherit the value as a result of the registered wildcard based subscription stored in the properties file.

 Inheritance of Permissions: Permissions that the user has been individually assigned, as well as permissions that
the user has as a result of membership in a group are inherited. For example, ifa user has permission to publish
on topic TEST.*, then the user also has permission to publish on TEST.new, TEST.hello, etc., but not
TEST.new.account.

Destination Properties and Permissions

Destination properties control message delivery behavior.

 Export and import properties allow messages to travel between EMS and external systems with configured
transports.
 The flowControl property specifies the target maximum size the server can use to store pending messages for the
destination.
 Prefetch creates a read-ahead buffer in each message consumer.
 Secure property enforces permissions on a destination whenever a user attempts to perform an operation on that
destination.
 Store identifies a storage configuration for messages produced with persistent delivery mode.
  Trace prepares log entries to record when messages are produced or consumed on the destination.

Destination properties maxbytes, maxmsgs and overflowPolicy can be set on temporary topics and queues, using
inheritance. Properties are not shared between topics and queues.

The topic permission durable allows an application to create a consumer for a new durable subscription. In contrast,
the use_durable permission allows an application to (re-)create a consumer only for an existing durable subscription.
Temporary destinations operate under access controls outside of the normal permissions system.
Apply and Revoke Permissions
 The wildcard inheritance of permissions, and the granting of permissions to users both directly and via group
membership, creates a comprehensive permissions system.
 Permissions can be revoked by removing or editing entries in the acl.conf file, using the revoke command in
tibemsadmin, or by using the administration API.
 Administrators can revoke permissions for users that have created topic subscriptions or are queue consumers.
Once the permission is revoked, the destination still exists, but the user can no longer perform that operation on
the destination. You cannot revoke a permission from a user that the user receives from a group. Also, you
cannot revoke a permission that is inherited from a matching wildcard destination. The revoke administrative
operation only removes permissions from an individual destination or wildcard. The revoke operation cannot
prevent inheritance of a permission resulting from a matching wildcard’s permission.

Administrative Permissions
Administrator permissions control what administrators can view and change in the server only when using the
administration tool. Administrator commands create entries in each of the configuration files (for example, tibemsd.conf,
acl.conf, routes.conf, and so on).Access to the configuration files must be controlled so that only certain system
administrators can view or modify the configuration files. Use your file system permissions to prevent uncontrolled access
to the server’s configuration files. You cannot grant or revoke administrator permissions from any user that is a member of
the $admin group.

Administrative permissions:

 Administrative permissions are granted and revoked using the grant and revoke commands. Global and
destination-level permissions are granted and revoked separately using applicable administrator commands.
 If a user has both global and destination-level administrator permissions, the actions that the user can perform are
determined by combining all global and destination-level administrator permissions granted to the user.
 The admin user or all users in the $admin group can grant or revoke any administrator permission to any user.
All other users must be granted the change-admin-acl permission before they can grant/revoke administrator
permissions to other users. If a user has the change-admin-acl permission, that user can only grant or revoke
permissions that have been granted to the user.

Destination level permissions control the administration functions a user can perform on a specific destination, like, view
information for destination, create specified destination, delete destination, change properties for destination, etc
Protection Permissions
 An administrator is able to view users that have a different protection permission set, but the administrator can
only perform actions on users with the same protection permission, i.e. Administrator with protect2 is limited to
govern only users with protect2.
 There are four protection permissions, protect1, protect2, protect3, and protect4 that allow you to create four
groups of administrators. You can grant a protection permission, in addition to the all permission. This signifies
that the user has all administrator privileges for anyone who also has the same protection permission.
  For example, SalesAdmin is able to perform any action on any user in the sales group, as well as see any users in
the engineering group. However, SalesAdmin is not able to grant permissions, change passwords, delete users
from, or perform any other administrative action on users of the engineering group. However, a user of a $admin
group is able to perform any action on any user, regardless of their protection permission.

Security with Enterprise Message Service

 Various security options available with Enterprise Message service are authorization, authentication, encryption,
and delegated administration.
 By default the Authorization is disabled. Enabling this parameter requires the server to verify the user credentials
and permissions on secure destinations.
 Enterprise Message Service servers can use SSL for secure data exchange or for client authentication. For
optimal performance the preferred solution is to use SSL only to authenticate clients.

SSL with Enterprise Message Service

 Secure Sockets Layer is a protocol for transmitting encrypted data by way of internet or internal network.
 SSL works by using public and private keys to encrypt data that is transferred over the SSL connection.
 Enterprise Message Service server and the JMS C client use OpenSSL for SSL support.
 Enterprise Message Service Java clients can use either JSSE (from Sun JavaSoft) or the SSL implementation
from Entrust. It also includes JSSE; if you wish to use Entrust, you must purchase and install the Entrust SSL
implementation separately.

Client Authentication Levels And Parameters

Depending on the security requirement of the application and internal security department of the organization, Enterprise
Message Service can be configured to provide the following levels of security for client authentication:

 No client authentication – This is default behavior with no security at all. Any client application can connect to
the server.
 Authentication of valid digital certificate – With this level of security, any user with a valid identity can connect
to the TIBCO EMS server.
 Authentication of valid identity and the username matches the CN field from client’s certificate and has valid
password for the user. This level guarantees that an illegal user cannot work with a valid certificate stolen from a
legal user.

Following are the parameters for client authentication:

 ssl_require_client_cert: Only accepts SSL connections from clients that have digital certificates
 ssl_server_trusted: List of trusted certificates, must be in PEM, DER, or PKCS#7 format
 ssl_use_cert_username: Extracted from the CN field of the client’s digital certificate
 ssl_cert_user_specname: Applications connecting as the user in ssl_cert_user_specname are authenticated
based on the CN name in their identity certificate
 ssl_identity: File containing client certificate and (optionally) extra issuer certificate(s), and the private key
 ssl_password: Private key/PKCS#12 password

Server Authentication Levels and Parameters

Depending on the security requirement of the application and internal security department of the organization, TIBCO
EMS can be configured to provide the following levels of security in terms of EMS server authentication:
  No server authentication – No security. Client trusts any server.
 Authentication with valid digital certificate – With this level of security, client verify server’s digital certificate.
 Authenticated if the server has a valid certificate, and the CN field in the certificate matches expected hostname
specified by the client. This level guarantees protection from an illegal application posing as a TIBCO EMS
server.

Server Authentication parameters are:

 ssl_server_identity: The server’s digital certificate in PEM, DER, or PKCS#12 format

 ssl_verify_host: Specifies whether client should verify server’s certificate
 ssl_trusted: List of trusted certificates
 ssl_verify_hostname: Specifies that the client should verify the name in the CN field of the server’s certificate
 ssl_expected_hostname: Specifies the name the server is expected to have in the CN field of the server’s
certificate

Cipher Suites
 A cipher suite is a set of algorithms that help secure a network connection that uses Secure Socket Layer (SSL).
 Enterprise Message Service uses OpenSSL to provide SSL support. Therefore, the cipher suite names can be
specified as the OpenSSL name for the cipher suite.
 Cipher suites are specified using ssl_server_ciphers parameter in the configuration file.
 When specifying cipher suites, you specify a qualifier (for example, + to add the suite) followed by the cipher
suite name. You can list more than one cipher suite by separating each suite name with a colon (:).

Configure SSL in Server and Client

SSL configuration in server:

 To use SSL, each instance of tibemsd must have a digital certificate and a private key.
 Server parameters: Specify server digital certificate parameters.
 Client parameters: Specify parameters needed to verify client identity.
 Miscellaneous parameters: These are various parameters needed for SSL communication. Details are as follows:
o ssl_dh_size: Size of the Diffie-Hellman key. Can be 512, 768, 1024, or 2048 bits. The default value is
1024. This key is not used for cipher suites available for export.
o ssl_server_ciphers: Specifies the cipher suites used by the server; each suite in the list is separated by
a colon (:). This parameter must follow the OpenSSL cipher string syntax.

SSL configuration in client:

 A client that uses an SSL connection to Enterprise Message Service server must have the following JAR files
included in the CLASSPATH as shown in the slide.
 These files are included with Enterprise Message Service, and located in the $TIBEMS_HOME/lib directory.
 If entrusting on the JMS client is needed, you must separately purchase and install the Entrust libraries. If you
use the Entrust libraries, you must include them in the CLASSPATH before thetibcrypt.jar file.
 To use Entrust with JDK, you must download the unlimited strength policy JAR files from Sun's website and
install them in your local installation of JDK.
  Configure Enterprise Message Service™ User
Permissions
 Play Video

 In this exercise, configure various levels of user permissions by setting up an administration hierarchy and then
testing the setup.
 #Restore the config files
 sudo cp /home/tibco/Lab_Files/Solution/LabA/*.conf
/opt/tibco/ems/8.5/samples/config/
 Enter password: TIBCO7222

 #Start the EMS server
 cd /home/tibco/Scripts
 ./start-ems-server.sh

 #Start Admin tool and connect to server
 cd /opt/tibco/ems/8.5/bin
 tibemsadmin
 connect

 #Verify group TALKERS and create WATCHERS group
 show group TALKERS
 create group WATCHERS

 #Create users and add them to group
 create user observeWOMAN
 create user observeMAN
 add member WATCHERS observeWOMAN,observeMAN

 #Verify users are created
 show members TALKERS
 show members WATCHERS

 #Create topic groups
 create topic TOPIC.NEWS.TALK.> secure
 create topic TOPIC.NEWS.WATCH.> secure

 #Assign admin privileges to CHATWOMAN user
 grant admin CHATWOMAN view-all
 grant topic TOPIC.NEWS.TALK.> CHATWOMAN create,modify,delete,purge

 #Assign admin privileges to CHATMAN user
 grant topic TOPIC.NEWS.TALK.> CHATMAN publish,subscribe,durable,view
 Test the capabilities of CHATWOMAN.

 #Connect admin tool to server as CHATWOMAN user
  connect
 Login name: CHATWOMAN
 Password: CHATWOMAN

 #Commands to check capabilities of CHATWOMAN user
 show topics
 create topic TOPIC.NEWS.TALK.1
 addprop topic TOPIC.NEWS.TALK.> store=$sys.failsafe
 addprop topic TOPIC.NEWS.WATCH.> store=$sys.failsafe

 #Connect admin tool to server as CHATMAN user
 connect
 Login name: CHATMAN
 Password: CHATMAN

 #Commands to check capabilities of CHATMAN user
 show topics
 show topic TOPIC.NEWS.TALK.>

Configure Delegated Administration

Play Video
In this exercise, delegate administration and test the protection permissions assigned.
#Start Admin tool and connect to server
connect
Login name: admin (press <Enter> key for password)

#Grantprotection permissions to WATCHERS group and assign observeMAN user as

the administrator
grant admin WATCHERS protect1
grant admin observeMAN protect1,all

#Grant the protection permissions to the TALKERS group, and assign the
CANTCHATMAN user as the administrator
grant admin TALKERS protect2
grant admin CANTCHATMAN protect2,all

#Set permissions for a member in WATCHERS group

set password observeWOMAN newObserver

#Set permissions for a member in TALKERS group

set password CHATWOMAN CHATPERSON

Configure Enterprise Message Service™ server for SSL

In this exercise, configure your TIBCO Enterprise Message Service server to listen for SSL
connections.

For this exercise, set the server identity using the following digital certificates.

To use an SSL connection with the TIBCO Enterprise Message Service server, a client must
include these JAR files in the CLASSPATH.

These JAR files are installed in /opt/tibco/ems/8.5/lib

Verify the client CLASSPATH environment variable
echo $CLASSPATH

#To see each CLASSPATH entry in a separate line

echo $CLASSPATH | sed "s/:/\\n/g"

#open tibemsd.conf file for editing

cd /opt/tibco/ems/8.5/samples/config
sudo gedit tibemsd.conf
password: TIBCO7222

#Start the server with SSL tracing

source ~/.bashrc
cd /opt/tibco/ems/8.5/samples/config
/opt/tibco/ems/8.5/bin/tibemsd64 -config tibemsd.conf -ssl_trace -
ssl_debug_trace

#Start Admin tool and connect to server

cd /opt/tibco/ems/8.5/bin
tibemsadmin
connect
Login name: admin (press <Enter> key for password)

#Connect Admin to server using SSL connection port

connect ssl://localhost:7333

#Create a topic
create topic EMS.SSL

#Run the tibjmsSSL client program

/home/tibco/Lab_Files/Export/LabB/Scripts/Unverified_Connection.sh

Enable Client and Server Authentication

  In this exercise, enable client authentication followed by the server authentication. Client authentication makes it
mandatory for the clients to present a valid digital certificate to TIBCO Enterprise Message Service server to
connect successfully (and prevents rogue clients from logging into the server).
 Use the following digital certificates to set the client identity.
 Server authentication makes it mandatory for the server to present its digital certificate to the client, when a client
requests a connection to the server. Configure the server and client to have encrypted communication with each
other using an SSL port.
 #Configure SSL client connections
 cd /opt/tibco/ems/8.5/samples/config
 sudo gedit tibemsd.conf
 password: TIBCO7222

 #Start TIBCO Enterprise Message Service server with SSL tracing
 cd /home/tibco/Lab_Files/Export/LabB/Scripts
 ./Start_EMS_SSL_mode.sh

 #Run the tibjmsSSL program
 cd /opt/tibco/ems/8.5/samples/java
 source setup.sh
 java tibjmsSSL -server ssl://localhost:7333 -topic EMS.SSL -ssl_trace

 #Run the tibjmsSSL program with valid digital certificate
 cd /home/tibco/Lab_Files/Export/LabB/Scripts
 sudo gedit Client_Authentication.sh
 password: TIBCO7222
 ./Client_Authentication.sh

 #Run the tibjmsSSL program for server authentication
 sudo gedit Clt_Svr_NoVerifyHost.sh
 ./Clt_Svr_NoVerifyHost.sh

 #To backup configuration files
 sudo cp /opt/tibco/ems/8.5/samples/config/*.conf
/home/tibco/Lab_Files/Export/LabB
 Enter password: TIBCO7222

Destination Bridging and Routing

Need for Destination Bridging
 Destination bridging forwards message between different destinations.
 TIBCO Enterprise Message Service provides a server-based solution.
 You can create bridges between destinations so that messages sent to one destination are also delivered to all
bridged destinations.
 Following are the scenarios that require bridging:
o Some applications require the same message to be sent to more than one destination, and the
destinations may be of different types.
 o For example, an application may send messages to a queue for distributed load balancing. That same
application may also need the messages to be published to several monitoring applications.
o Another example is an application that publishes messages to several topics. All messages must also be
sent to a database for backup and for data mining. A queue is used to collect all messages and send
them to the database.

Destination Bridging Options

 Bridges are created between one destination and one or more other destinations of the same or of different types.
That is, you can create a bridge from a topic to a queue or from a queue to atopic.
 You can also create a bridge between one destination and multiple destinations. For example, you can create a
bridge from topic a.b to queue q.b and topic a.c.
 When specifying a bridge, you can specify a particular destination name, or you can use wildcards.
 For example, if you specify a bridge on topic foo.* to queue foo.queue, messages delivered to any topic matching
foo.* are sent to foo.queue.
 By default, all messages sent to a destination with a bridge are sent to all bridged destinations. You can
optionally specify a message selector for each bridge to determine which messages are sent over that bridge.
 Message selectors are optional filters that transfer the filtering work to the JMS provider, rather than the message
consumer.
 A message selector is a String that contains an expression. The syntax of the expression is based on a subset of
the SQL92 conditional expression syntax.

Message Selector
 A message selector is a string that lets a client program specify a set of messages, based on the values of message
headers and properties. A selector matches a message if, after substituting header and property values from the
message into the selector string, the string evaluates to true. Consumers can request that the server deliver only
those messages that match a selector.

As mentioned in the previous slide, you can optionally specify a message selector for each bridge and route to determine
which messages are sent over that bridge.

 Message Selector identifiers:

Identifiers refer to the values of message headers and properties, but not to the message body. Identifiers refer either to
message header names or property names. The type of an identifier in a message selector corresponds to the type of the
header or property value. If an identifier refers to a header or property that does not exist in a message, its value is NULL.

 String Expressions:

Every selector is a conditional expression. A selector that evaluates to true matches the message; a selector that
evaluates to false or unknown does not match. Three types of expressions are available, naming, Arithmetic,
Conditional, and Order of evaluation.
Message Selector Operators
 Logical Operator: Logical operators in precedence order: NOT, AND, OR.
 Comparison Operator: =, >, >=, <, <=, <> (not equal).
o These operators can compare only values of comparable types. (Exact numeric values and approximate
numerical values are comparable types.)
o Attempting to compare incomparable types yields false. If either value in a comparison evaluates to
NULL, then the result is unknown (in SQL3-valued logic).
 o Comparison of string values is restricted to = and <>.
o Two strings are equal if and only if they contain the same sequence of characters. Comparison of
Boolean values is restricted to= and <>.
 Arithmetic Operator: Arithmetic operators in precedence order are +, -, *, and /.
 Between operator: Defines a range. This operator includes its endpoints. For example, age between 5 and 9 is
equivalent to >=5 AND age <=9.
 String set Membership: The identifier must evaluate to either a string or NULL. If it is NULL, then the value of
this expression is unknown. You can use a maximum of 32,767 string-literalsin the string set.
 Pattern Matches: The pattern-value is a string literal, in which some characters bear specialmeaning:
o _ (underscore) can match any single character.
o % (percent) can match any sequence of zero or more characters.

Define a Destination Bridge

 Configure bridges in the bridges.conf configuration file. In the configuration file source andtarget destinations
are defined. Use the syntax shown in the slide to specify a bridge. The parameters in the syntax are:
o destinationType: type of the destination (topic/queue)
o destinationName: name of the destination from which you wish to create a bridge
o destinationToBridgeTo: name of the destination you wish to create a bridge to
o messageSelector: optional
 Next, create the destinations and
 Then restart Enterprise Message Service server.
 Use Admin tool to verify the bridges are created.

Routing Fundamentals
 Enterprise Message Service provides the ability for servers to route messages between each other.
 Topic messages can be routed across multiple hops, provided there are no cycles (that is, the message cannot be
routed to any server it has already visited).
 Queue messages can travel at most one hop to any other server from the server that owns the queue. Each route
forwards messages between corresponding destinations (that is, global topics with the same name, or explicitly
routed queues) on its two servers.
 Routes are bidirectional; that is, each server in the pair forwards messages along the route to the other server.
 Enterprise Message Service stores and forwards messages in most situations to provide operation when a route is
not connected.
 Route types:
o An active route is specified in a server’s route configuration file and initiates the connection to the
other, routed server.
o A passive route is not specified in the server’s routes configuration, and the connection is initiated to
that server from a server with an active route.
 Because passive routes are not specified in a server’s configuration, route properties cannot be specified or
changed on passive routes. Only active routes have configuration properties.

Zone
 With Enterprise Message Service, routes are arranged in zones. A zone is a named set of routes. Every route
belongs to a zone. Zones restrict the behavior of routes, so you can configure complex routing paths.
 There are two zone types: one-hop (1-hop) and multi-hop (mhop). Type of a zone affects the forwarding
behavior of its routes, so you can configure complex routing paths.
 In a 1-hop zone, messages are restricted to just one hop from an Enterprise Message Service server to its
neighboring Enterprise Message Service server through the 1-hop route. Alternatively, when routes belong to a
 multi-hop zone, messages can travel an unlimited number of hops along routes in that multi-hop zone. When
creating multi-hop zone, cycle dependency i.e. parallel routing paths should be avoided.
 A single server can support multiple routes, each route belonging to a different zone and zone type. Zones affect
topic messages, but not queue messages. Queue messages always travel only one hop, even within multi-hop
zones.
 One-hop zone example shown on the left side of the slide forward messages from both branches to both Finance
and Marketing. When the left route is configured as one hope and the msg is produced on Branch A then it will
reach to only Finance and Marketing as from Branch A, Finance and Marketing are at one hop.
 The routing graph seems to contain a cycle: the path from Branch A to Marketing to Branch B to Finance
duplicates the route from Branch A to Finance. However, since these routes belong to the one-hop zone, it is
impossible for messages to travel the longer path. Instead, this limitation results in the desired result, forwarding
from Branch A to Marketing and Finance, and from Branch B to Marketing and Finance.
 In the multi-hop zone example, when a client of Japan1 produces a message, it travels one hop to reach Japan
Finance. When the message reaches Japan Finance, it crosses into zone Finance. Japan Finance forwards the
message to Finance, which in turn forwards it to the USA. When the message reaches USA Finance, it crosses
into zone USA (with hop count reset to zero); USA Finance then forwards it one hop to USA1.

Single Vs Multi-hop Routing

Single-hop

 Single-hop routing is supported by both topics and queues.

 It allows the topic message to flow to adjacent neighbors. The accepting neighbor does not subsequently forward
the topic message to another neighbor.

Multi-hop

 Multi-hop routing is not supported by queues.

 It allows the topic messages to flow between more than one neighbor in the same zone.
 It also detects loops and does not allow a link between neighbors that results in a loop.

Create Routes
A route can be created from either of the available following options:

 Use Administration tool

 Edit routes.conf file
 Use Java Admin API

To create a route by Administration tool use the following command shown in the slide. Parameters used in the syntax are:

 name: Name of the server you wish to route to. It is also the name of the route.
 URL: URL for the remote server that includes protocol and port (URL can be a comma-separated list of URLs
for fault-tolerant servers, if fault-tolerance is configured in your environment).
 Zone_name: Specifies that the route belongs to the routing zone with this name.
 Properties: A space-separated list of connection properties for the route (this is a list of properties for
configuring the Secure Sockets Layer (SSL) protocol for the route).

Alternatively, you can add a route to the routes.conf file.

Routed Topic and Queue Messages
  For topic messages that should travel over routes, the topic property global must be set on each server in the
route path.
 Servers to which a route is specified create a durable subscriber for the topic subscriber on the other side of the
route. This allows topic messages to be stored on the server and later delivered to the topic subscriber if the route
goes down.
 Each active route creates a "proxy" durable subscriber at the target server. This durable subscriber allows
recovery of messages which might be lost as a result of network or EMS server failures within the routed path.
 The JMS specification requires that the JMS provider deliver to a regular subscriber all messages published
while the subscriber is connected. Since the entire set of Enterprise Message Service servers forms a JMS
provider, the presence of proxy durable subscriber(s) allows Enterprise Message Service to support this
requirement.
 Image shown at the left of the slide shows routing of topic messages. There are three servers, namely, Server A,
Server M, and Server B. All the three servers configure a global topic T.
o At bottom right of the above figure, a client of server B creates a subscriber to T.
o Server B, registers interest in T on behalf of the client by creating an internal subscriber object.
o Because a route connects servers M and B, server B propagates its interest in T to server M. In
response, M creates an internal subscriber to T on behalf of server B. This subscriber ensures that M
forwards (that is, delivers) messages from topic T to server B. Server B behaves as a client of server M.
o Similarly, because a route connects servers A and M, server M propagates its interest in T to server A.
o In response, A creates an internal subscriber to T on behalf of server M. This subscriber ensures that A
forwards messages from topic T to M. Server M behaves as a client of server A.
o When a producer client of server A sends a message to topic T, A forwards it to M. M accepts the
message on its topic T, and forwards it to B. B accepts the message on its topic T, and passes it to the
client.
 Servers route queue messages between the queue owner and adjacent servers. Image shown at the right of the
slide shows routing of queue messages.
o Server A and server B are connected by a route.
o Server A defines a global queue named Q1 and is the owner of Q1.
o Server B defines a routed queue Q1@A. This indicates that this queue depends upon and reflect their
home queue (that is, Q1 on server A). Note that the designation Q1@A is only for the purpose of
configuration; clients of B refer to the routed queue as Q1.
o When a queue sender connects to a routed server adjacent to the owner of the queue (i.e. when queue
sender connects to server B with routed queue) and sends messages to the queue, the routed queue
stores and forwards the messages to the queue owner i.e. server A. Server A deliver the messages to
Q1.
o The message is not available for consumers until it reaches the home queue. That is, queue receiver
client cannot consume the messages directly from server B. When multiple queue receiver clients are
present, only one client can consume the message.
o When a queue receiver connects to a routed server adjacent to the owner of the queue, the routed server
acts as a proxy receiver for the queue owner for that queue receiver.
o If the owner server goes down and becomes unavailable, any queue sender client connected to routed
server may still send messages to the queue. That is, if server A fails or the route from server A to
server B fails, server B continues to store messages from queue sender in its routed queue.
o The messages are stored and forwarded when server A becomes available again. The queue receiver,
however, are not able to receive messages when the queue owner becomes unavailable.

Routing and Authorization

This slide describes the authorization configurations to be done in routing.

 When a server’s authorization parameter is enabled, other servers that are actively connected to it must
authenticate themselves by name and password. Additionally, when routing a secure topic or queue, servers
consult the ACL specification before forwarding each message.
 The servers must grant one another appropriate permissions to send, receive, publish or subscribe.
 The image on the slide shows an example for authorization between active routes.
 o Server X has a queue named myQueue@ServerY defined as a routed queue. The global property is set
for this queue.
o Server Y has a queue named myQueue defined with the global property.
o Server X must have a user named Server Y and Server Y must have a user named Server X.
o A message is sent to Server X, and that message must be routed to the queue on Server Y. For this to
work, the Server Y user created on Server X must have the receive permission. Also, the Server X user
created on Server Y must have the send permission.

Configure Enterprise Message Service™ Destination Bridge

In this exercise, configure a bridge between a source Topic and two targets (Queue and Topic).

#Restore the original configuration files to config directory

sudo cp /home/tibco/Lab_Files/Original/*.conf
/opt/tibco/ems/8.5/samples/config/
Enter password: TIBCO7222

#Start the EMS server

cd /home/tibco/Scripts
./start-ems-server.sh

#Connect the administration tool to the server as admin user

cd /opt/tibco/ems/8.5/bin
tibemsadmin
connect (Press <Enter> button for Login name and Password)

#Create topics
create topic source.topic.xx
create topic target.topic.xx
create queue target.queue.xx

#Set the source and targets for the bridge

create bridge source=topic:source.topic.XX target=queue:target.queue.XX
create bridge source=topic:source.topic.XX target=topic:target.topic.XX

#View bridge details

show bridge topic source.topic.XX
Test Destination Bridging
In this exercise, test the bridge you have configured in the last exercise.

Configure Routing
 In this exercise, configure routing between two Enterprise Message Service™ servers.
 Later create a global topic between EMS-SERVER and EMS-SERVER2, so that message sent on this topic is
routed between the two servers.
 To route messages among servers, the destination must be specified as “global”.
 Global topics can be routed among any number of servers; global queues, on the other hand, can only be routed
between two servers.
 #Commands to create a new folder
 cd /opt/tibco/ems/8.5/samples
 sudo mkdir config2
 password: TIBCO7222

 #Copy all the files from config folder to the newly created folder
 sudo cp -r /opt/tibco/ems/8.5/samples/config/*
/opt/tibco/ems/8.5/samples/config2

 #Change the owner of datastore files in config2 folder
 cd /opt/tibco/ems/8.5/samples/config2/datastore
 sudo chown tibco:tibco async-msgs.db sync-msgs.db meta.db

 #Grant read/write permission to the .conf files
 cd /opt/tibco/ems/8.5/samples/config2
 sudo chmod a+rwx *.conf

 #Commands to open and edit the config file
 cd /opt/tibco/ems/8.5/samples/config
 sudo gedit tibemsd.conf
 password: TIBCO7222

 #Commands to open and edit routes.conf file
 sudo gedit routes.conf

 #Start the server
 ./start-ems-server.sh

 #Commands to open and edit the config file for second server
 cd /opt/tibco/ems/8.5/samples/config2
 sudo gedit tibemsd.conf
 password: TIBCO7222

 #Start the second server
 cd /opt/tibco/ems/8.5/samples/config2
 source ~/.bashrc
 /opt/tibco/ems/8.5/bin/tibemsd64 -config tibemsd.conf

 #Start administration tool and connect to server as admin user
 connect tcp://localhost:7222 (for user name and password press <Enter>)

 #Create route
 create route EMS-SERVER-2 url=tcp://localhost:7333

 #Create a global topic in EMS-SERVER
 create topic route.topic1 global

 #Create a global topic in EMS-SERVER-2
 tibemsadmin
 connect tcp://localhost:7333 (for user name and password press <Enter>,
if prompted)
  create topic route.topic1 global

 # Run consumer client program to test topic-based routing
 cd /opt/tibco/ems/8.5/samples/java
 source setup.sh
 javac *.java
 java tibjmsMsgConsumer -server "tcp://7333" -topic route.topic1

 #Run producer client program
 source setup.sh
 javac *.java
 java tibjmsMsgProducer -server "tcp://7222" -topic route.topic1
"Hello.This is a message from EMS-SERVER."

Explore Queue-based Routing

 In this exercise, create a global queue between EMS-SERVER and EMS-SERVER-2.
 Messages sent to this queue are routed between the two servers.
 #Command to start the Topic Subscriber
 java tibjmsMsgConsumer -topic source.topic.XX

 #Command to start the other Topic Subscriber
 java tibjmsMsgConsumer -topic target.topic.XX

 #Start a Queue Listener
 java tibjmsMsgConsumer -queue target.queue.XX

 #Run a topic publisher
 java tibjmsMsgProducer -topic source.topic.XX "Message from Source"

Unit 4: Lecture
Message Persistence Modes
 JMS messages with PERSISTENT delivery mode are guaranteed to be delivered in case of the provider failure.
 TIBCO Enterprise Message Service™ writes these messages into persistent storage only if they are sent to a
queue or to a topic with at least one durable subscriber. The messages sent to topics with no durable subscribers
are stored in memory, eliminating unnecessary I/O.
 Hence, there are two message storage modes in Enterprise Message Service: disk-based and memory-based.
 For disk-based storage, it is further divided between the options of file-based stores or database stores.
 Each has controls to ensure the system is not overwhelmed by the persisted messages.
  Enterprise Message Service also offers an additional message store option mstore, designed for systems storing
large numbers of messages who desire fast recovery times in the event of a failover.

Memory-Based Storage
Following are the features of memory-based storage:

 This storage does not survive system or instance failure.

 It is good for simple request reply messaging patterns and not for complex patterns
 When using memory-based storage it is very important to ensure expiration of messages.

Memory-based storage is configured in tibemsd.conf file.

 In this file, set the max_msg_memory parameter to specify how much EMS memory should be used for
messages. Best practice indicates that the amount of memory allocated should be in the range 20-25% of total
memory used by the EMS server.
 Also in tibemsd.conf is the reserve_memory parameter. This parameter comes into play when server memory
resources are fully utilized. When reserve_memory is set to a non-zero value, the EMS server allocates a block of
memory to be utilized in low memory situations to keep the EMSserver from becoming unstable.
 The reserve_memory parameter, in conjunction with immediate message consumption or disposal, can be used as
a reactive mechanism to avoid memory-based failures.

Allocate Memory for Messages

 The parameter msg_pool_block_size can be found in tibemsd.conf.
 It controls how the EMS server allocates storage pools. When the pool is exhausted, the server increases the pool
by this size. As long as additional storage is available.
 The size represents the approximate number of messages that a block can accommodate (not the number of
bytes).
 The value can be in the range of 32 to 65536. When this parameter is not present, the default
msg_pool_block_size is 128.
 Destinations properties can be used to control memory used for messages as well. The maxbytes property of a
destination specifies how much memory the destination allocates for message storage.
 The maxmsgs property specifies the total number of messages that a destination can store.

Disk-Based Persistence Overview

 Disk-based persistence delivery mode ensures delivery of messages to the destination on the server in almost all
circumstances.
 The performance of this mode is slower than memory-based storage.
 This mode provides various ways to determine the discard policy. The discard policy determines the behavior of
the queue when the maximum number of messages (events) that the queue can hold is reached.

Disk-Based Persistence Options

TIBCO Enterprise Message Service allows to configure following types of stores:

 File-Based Stores: File-based stores allow destinations to persist messages to files.

 o These stores are enabled by default and EMS server automatically creates three
default store files named $sys.nonfailsafe, $sys.failsafe and $sys.meta during the
installation.
o Persistent messages without a store property designation are written to
$sys.nonfailsafe by default. The server writes messages to this store using
asynchronous I/O calls.
o When a destination is associated with $sys.failsafe store, messages are written
synchronously. The server writes messages to this store using synchronous I/O
calls.
o $sys.meta store is used by the server to write state information about durable
subscribers, fault-tolerant connections, and other metadata. You can use the
default store files, or create your own file-based stores.
 Database Stores: Database stores allow destinations to persist messages to database
tables.
o The EMS server connects to a database, and store messages in one or more
database instances.
o The server connects to the database using Hibernate Core for Java to interface
between the database and the EMS server.
 mstore: The mstore is designed to recover quickly after a failover.
o When mstores are in use, the EMS server starts quickly, but may run more slowly
until the mstore cache is fully loaded. This happens because the EMS server
continually monitors the store in the background.
o The server reads through the mstore incrementally and discards stale data, such as
purged and expired messages.
o As a result, expired and purged messages are not immediately removed from the
mstore, and remain in the store longer than they would in a file-based or database
store, although they are not delivered to the consumer.

Stores.conf File
Stores.conf file defines the locations, either store files, mstore, or a database, where the EMS server will store messages or
metadata. You can configure one or many stores in the stores.conf file.

As discussed earlier, by default, 3 file-based stores are declared: $sys.meta, $sys.nonfailsafe, and $sys.failsafe.

The image in the slide shows the configuration for file store, dbstore and mstore. Configuration parameters for file store
and mstore are as follows:

 The type parameter of the store defines whether the messages are persisted to a file, mstore or database table. The
options are file, dbstore, or mstore.
 File parameter specifies the filename that is used when creating the store file. The location for this file can be
specified using absolute or relative path names. If no path separators are present, the file will be saved in the
location specified by the store parameter in the tibemsd.conf file. This parameter is required for both file and
mstore types.
 The mode parameter is only used with file-based stores and specifies whether messages are persisted using
buffered I/O or raw I/O. The options are async or sync.
 File crc parameter specifies whether the EMS server uses CRC to validate data integrity when reading the store
files. It is only used with file store.
  Mstore_truncate parameter is used to truncate the mstore files, to give up unused disk space. Scan_iter_interval
determines the span of time between each interval of the store scan. These two parameters are used only with
mstore.

For the database store type, all the four of the parameters shown in the image are required.
Parameter dbstore_driver_url is the connection string of the database,
with dbstore_driver_username and dbstore_driver_password specifying the credentials needed for database select,
insert, update and delete access.
Multiple Store Configuration Example
 The slide give details of an example to configure multiple stores. Following configuration is done: Two file-
based stores naming SafeStore and LocalStore are configured and these stores are assigned to the topics and
queues from EMS administrator console as shown in the images on slide.

This example results in the following assignment of message data to files:

 T1 to datastore/async-msgs.db buffered (default)

 T2 to /opt/ems.db buffered
 Q.A to /raid/ems.db un-buffered (inherited from Q.*)
 Q1 to /opt/ems.db buffered
 All metadata to datastore/meta.db buffered (default)

Note: In tibemsd.conf, the store parameter must point to the parent directory where the store files are located.
Database Implementation
Database implementation requires:

 Hibernate Core for Java and related JAR files.

 A database server that is supported by Hibernate, the corresponding dialect, and the appropriate JDBC driver.
The database server must be running, and the databases that the EMS server connects to must have already been
created by the database administrator.
 A username with read-write permissions and a password to the database server.

The reason the database store implementation requires a Java Virtual Machine is to federate the EMS Server from the
persistence operations. Should the JVM fail, the failure is localized, allowing the EMS Server to continue messaging
operations.
Configure Database Persistence
Database persistence requires following configuration steps:

 After installing the Hibernate Core, the first step in configuring database persistence is to enable Java Virtual
Machine binary in EMS server. This is done by defining jre_library path in tibemsd.conf file.
 Next, add following database parameters in tibemsd.conf file:
o dbstore_classpath – paths to the Hibernate, JDBC, and EMS jar files
o dbstore_driver_name – JDBC driver class
o dbstore_driver_dialect – Hibernate SQL version for your database
 Then setup and configure stores in the stores.conf file.
 Associate your destination with the new database store in topics.conf and queue.conf files by using the following
command:
o addprop destination destination_name store=store_name
 Finally, export the database tables using the tibemsd_util.jar program available in the bin folder.
EMS Message Persistence Benefits
Benefits of TIBCO Enterprise Message Service message persistence are:

 Messages can be retrieved and recovered quickly in the event of failure.

 Ability to create multiple stores allows segmentation of data by volume.
 It supports integration with existing database implementation.

Configure a File Store

In this exercise, configure a file store for use with a destination, compact a store and purge a queue.

#Restore the original configuration files to config directory

sudo cp /home/tibco/Lab_Files/Original/*.conf
/opt/tibco/ems/8.5/samples/config/
Enter password: TIBCO7222

#open stores.conf file for editing

cd /opt/tibco/ems/8.5/samples/config
sudo gedit stores.conf
Password: TIBCO7222

#Start EMS server

cd /home/tibco/Scripts
./start-ems-server.sh

#connect the administration tool to the server as admin user

cd /opt/tibco/ems/8.5/bin
tibemsadmin
connect (press <Enter> for Login name and password)

#Create a queue and associate with store

create queue myqueue store=queue_msgs

#Send messages to myqueue

cd /opt/tibco/ems/8.5/samples/java
source setup.sh
java tibjmsMsgProducerPerf -queue myqueue -size 2000 -count 20000 -delivery
PERSISTENT

#Verify that the Message Count

show store queue_msgs

#Compact the store queue_msg

compact queue_msgs 10

#Purge the message

purge queue myqueue

#Backup config files

sudo cp /opt/tibco/ems/8.5/samples/config/*.conf
/home/tibco/Lab_Files/Export/LabD
Enter password: TIBCO7222
Create a Store
 Open a new terminal and enter the command as shown or copy it from the code snippet to restore the original
configuration files to config directory
 Close the terminal window
 Create a store named queue_msgs
o Open a new terminal and enter the commands as shown or copy them from code snippet to open stores
conf file for editing
o Add the following lines as shown at the end of the file
o [queue_msgs]
o type=file
o file=queue-msgs.db
o mode=sync
o file_truncate=enabled
o Save and close the file
 Close the terminal

Create a Queue and Associate it with the Store

 Open a new terminal, name it as EMS Server, and enter the commands as shown or copy them from code
snippet to start the server
 Open a new terminal tab, name it as Admin and enter the commands as shown or copy them from code snippet
to connect the administration tool to the server as admin user
 From the same terminal, enter the command as shown to create a queue and associate it with the store

Send Messages to Queue and Examine the Message Storage

 Open a new terminal and enter the commands as shown or copy them from code snippet
o Wait for the program to finish sending 20,000 messages
o Close the terminal
 In the Admin terminal window, enter the command as shown
o Verify that the Message Count value reflects the number of messages sent in the previous step
 Now, verify the messages have been persisted
o Using the File Explorer, navigate to /opt/tibco/ems/8.5/ samples/ config/ datastore directory
 `Observe the size of the queue-msgs.db file

Compact the Store and Purge the Messages

 Use administration tool from Admin terminal and enter the command as shown or copy it from code snippet to
compact the store size
o Enter yes to compact
 Observe the message about the change in file size of queue-msgs.db
 From the same terminal enter the command as shown or copy it from code snippet to purge messages
o Enter yes to purge
 Refresh the File Explorer to observe the change in queue-msgs.db file size
o It may take few minutes before the change becomes visible
 Shutdown the sever (use <Ctrl+c>)
 Close all the terminal windows
 Open a new terminal window and enter the commands as shown or copy them from code snippet to save the
updated config files
  This completes the exercise
 Restore the original configuration files to config directory
 sudo cp /home/tibco/Lab_Files/Original/*.conf
/opt/tibco/ems/8.5/samples/config/
 Enter password: TIBCO7222

 #open stores.conf file for editing
 cd /opt/tibco/ems/8.5/samples/config
 sudo gedit stores.conf
 Password: TIBCO7222

 #Start EMS server
 cd /home/tibco/Scripts
 ./start-ems-server.sh

 #connect the administration tool to the server as admin user
 cd /opt/tibco/ems/8.5/bin
 tibemsadmin
 connect (press <Enter> for Login name and password)

 #Create a queue and associate with store
 create queue myqueue store=queue_msgs

 #Send messages to myqueue
 cd /opt/tibco/ems/8.5/samples/java
 source setup.sh
 java tibjmsMsgProducerPerf -queue myqueue -size 2000 -count 20000 -
delivery PERSISTENT

 #Verify that the Message Count
 show store queue_msgs

 #Compact the store queue_msg
 compact queue_msgs 10

 #Purge the message
 purge queue myqueue

 #Backup config files
 sudo cp /opt/tibco/ems/8.5/samples/config/*.conf
/home/tibco/Lab_Files/Export/LabD
 Enter password: TIBCO7222
Create a Queue and Associate it with the Store
#Restore the original configuration files to config directory
sudo cp /home/tibco/Lab_Files/Original/*.conf
/opt/tibco/ems/8.5/samples/config/
Enter password: TIBCO7222

#open stores.conf file for editing

cd /opt/tibco/ems/8.5/samples/config
sudo gedit stores.conf
Password: TIBCO7222

#Start EMS server

cd /home/tibco/Scripts
./start-ems-server.sh

#connect the administration tool to the server as admin user

cd /opt/tibco/ems/8.5/bin
tibemsadmin
connect (press <Enter> for Login name and password)

#Create a queue and associate with store

create queue myqueue store=queue_msgs

#Send messages to myqueue

cd /opt/tibco/ems/8.5/samples/java
source setup.sh
java tibjmsMsgProducerPerf -queue myqueue -size 2000 -count 20000 -delivery
PERSISTENT

#Verify that the Message Count

show store queue_msgs

#Compact the store queue_msg

compact queue_msgs 10

#Purge the message

purge queue myqueue

#Backup config files

sudo cp /opt/tibco/ems/8.5/samples/config/*.conf
/home/tibco/Lab_Files/Export/LabD
Enter password: TIBCO7222
Send Messages to Queue and Examine the Message Storage
Send Messages to Queue and Examine the Message Storage
Restore the original configuration files to config directory
sudo cp /home/tibco/Lab_Files/Original/*.conf
/opt/tibco/ems/8.5/samples/config/
Enter password: TIBCO7222

#open stores.conf file for editing

cd /opt/tibco/ems/8.5/samples/config
sudo gedit stores.conf
Password: TIBCO7222

#Start EMS server

cd /home/tibco/Scripts
./start-ems-server.sh

#connect the administration tool to the server as admin user

cd /opt/tibco/ems/8.5/bin
tibemsadmin
connect (press <Enter> for Login name and password)

#Create a queue and associate with store

create queue myqueue store=queue_msgs

#Send messages to myqueue

cd /opt/tibco/ems/8.5/samples/java
source setup.sh
java tibjmsMsgProducerPerf -queue myqueue -size 2000 -count 20000 -delivery
PERSISTENT

#Verify that the Message Count

show store queue_msgs

#Compact the store queue_msg

compact queue_msgs 10

#Purge the message

purge queue myqueue

#Backup config files

sudo cp /opt/tibco/ems/8.5/samples/config/*.conf
/home/tibco/Lab_Files/Export/LabD
Enter password: TIBCO7222
Compact the Store and Purge the Messages
Restore the original configuration files to config directory
sudo cp /home/tibco/Lab_Files/Original/*.conf
/opt/tibco/ems/8.5/samples/config/
Enter password: TIBCO7222

#open stores.conf file for editing

cd /opt/tibco/ems/8.5/samples/config
sudo gedit stores.conf
Password: TIBCO7222

#Start EMS server

cd /home/tibco/Scripts
./start-ems-server.sh

#connect the administration tool to the server as admin user

cd /opt/tibco/ems/8.5/bin
tibemsadmin
connect (press <Enter> for Login name and password)

#Create a queue and associate with store

create queue myqueue store=queue_msgs

#Send messages to myqueue

cd /opt/tibco/ems/8.5/samples/java
source setup.sh
java tibjmsMsgProducerPerf -queue myqueue -size 2000 -count 20000 -delivery
PERSISTENT

#Verify that the Message Count

show store queue_msgs

#Compact the store queue_msg

compact queue_msgs 10
#Purge the message
purge queue myqueue

#Backup config files

sudo cp /opt/tibco/ems/8.5/samples/config/*.conf
/home/tibco/Lab_Files/Export/LabD
Enter password: TIBCO7222

Unit 5: Lecture

EMS Fault Tolerance and Load Balancing

EMS Fault Tolerance
 TIBCO Enterprise Message Service™ offers fault tolerance in an event of server failover. This fault tolerant
operation provides high availability of system by configuring server redundancy.
 Enterprise Message Service™ servers are configured as primary and secondary servers to provide fault tolerance
for your environment.
 The primary and secondary servers act as a pair, with one of them starting in the active state and the other in the
standby state.
 The active server accepts client connections and performs the work of handling JMS messages, while the standby
server acts as a backup in case of failure.
 If the active server fails, the standby server take up operations and becomes the primary server.
 The primary and backup servers must both have access to a shared state.
o This shared state can be implemented as shared storage devices or through other mechanisms such as
replication.
o The shared state allows the backup server to take over any active connections and properly handle
persistent messages.
 Note: Only two servers can be used in a fault-tolerant configuration.

Shared State
 Shared state consists information about all the persistent messages for queues and topics, client connections and
metadata related to data delivery.
 During normal operation of the primary server, all persisted messages are stored then delivered. During a
failover, all shared state information that exists is retrieved by the backup server.
 Shared state can be implemented by shared storage or through other means such as replication. The shared state
must be accessible to both the primary and backup servers.
 To prevent the backup server from assuming the role of the primary server unnecessarily, the primary server
locks the shared state during normal operation. If the primary server fails, the lock is released, and the backup
server can obtain a lock on the shared state.

Failover and Message Delivery Mode

 Depending on the business logic, if the message needs to be available after FAILOVER, then that message needs
to be sent with PERSISTENT delivery mode.
  PERSISTENT mode has a greater performance overhead compared to NON_PERSISTENT mode as messages
are written to disk.
o When a producer sends a PERSISTENT message, the producer waits for the server to reply with a
confirmation.
o The message is persisted on disk by the server.
o When the store is configured with mode=sync (failsafe node), the message is written to store using
unbuffered I/O and then acknowledged to producing client.
o This increases the reliability in case of server failure.
 For NON_PERSISTENT mode, messages are written only to memory.

Storage Files
In tibemsd.conf, the store parameter points to the parent directory where the store files are located.

The EMS server defines three default store files to write the persistent messages and meta data:

 meta.db - information about durable subscribers, fault-tolerant connections and other metadata are stored in this
file
 sync.db - messages for failsafe destinations are stored in this file
 async.db - messages for non-failsafe destinations are stored in this file

Fault Tolerant Server Setup

To setup fault tolerance between Enterprise Message Service servers, following fault tolerance parameters are required to
be configured in tibemsd.conf file :

 Server: This parameter should be same for both primary and secondary servers.
 ft_active: When the backup server starts, it attempts to connect to the primary server. If the connection can be
established, the backup server enters standby mode for the primary. If the connection cannot be established, the
backup server becomes the primary server. The primary server should set the ft_active parameter to the URL of
the backup server. This allows the primary and backup servers to exchange roles in the event of a failure.
 ft_reconnect_timeout: When the primary server goes down and the backup server assumes the role of the primary
server during failover, all of the client connections can reconnect to the backup server and continue with
processing their current message state. The backup server reads the clients’ state from the shared state, and the
server can be configured to clean up any state information for clients that have not reconnected after a certain
period of time. The default value of this parameter is 60.
 SSL parameters: The fault tolerance parameters that begin with the prefix ft_ssl are used to secure
communications between pairs of fault tolerant servers. Few examples of ft_ssl parameters are ft_ssl_identity,
ft_ssl_private_key, ft_ssl_password, etc.

These parameters can be set from command line as well.

Fault Tolerant Client Setup

 To connect to a backup server in the event of a failure of a primary server, a client application must specify
multiple server URLs as part of the connection to the EMS server.
 This can be done in various ways, depending upon how the client connects to the server. In any method,
however, the server URLs for the primary and backup server are specified as a comma-separated list of URLs.
 The URLs in the list are tried in order. If a connection to the first URL fails, the next URL is used to attempt a
reconnection.
  The connections in the list are attempted in sequence (wrapping to the start of the list, if the first connection was
not the failed connection) until all URLs have been tried.
 If no connection is established after all URLs have been tried, the connection fails.
 Clients must connect to both the servers with same protocol either tcp or ssl. The example in the slide shows an
example to specify multiple URLs.

Detect Failover
The primary and backup servers detect failures of either server in two ways:

 Loss of the connection between the servers (for example, the socket for the fault-tolerant connection is
terminated).
 The primary and backup servers exchange heartbeats to indicate both are still operating. If there is a loss of
connectivity (for example, network failures that do not close the connection), the length of time between
heartbeats can be used to detect failures.

Parameters that needs to be configured in tibemsd.conf file to detect failover are:

 ft_heartbeat: This parameter specifies the time interval at which the server have to send aheartbeat signal to its
peer to indicate that it is still operating. Default value for this parameter is 3 seconds.
 ft_activation: This parameter indicates the maximum amount of time between heartbeat signals which indicates
that server has failed.

Message delivery on Failover

This slide describes the message delivery mechanism in case of failover.

 For topic-based messages, subscriber continues normal operation after a failover.

 For queue-based messages, any message that have been sent to receivers, but have not been acknowledged before
the failover, may be sent to other receivers immediately after the failover.
o A receiver trying to acknowledge a message after a failover may receive the
javax.jms.IllegalStateException.
o This exception signifies that the attempted acknowledgment is for a message that has already been sent
to another queue receiver.
o When the queue receiver encounters the javax.jms.IllegalStateException, the best course of action is to
call the Session.recover() method.
 Sessions with active transactions cannot commit the transaction after a failover to a backup server. Transactions
are active when at least one message has been sent or received by a transacted session and the session has not
issued a call to Session.commit().
o After a failover, when a client attempts to call the Session.commit() method, the application will throw
a javax.jms.TransactionRolledBackException.
 Clients that use transactions should account for this possibility and handle the exception in the event of a
failover.

Single Server Failover - Case Study

 The diagram in the slide shows the implementation of failover of two EMS servers.
 These two servers are not related to each other.
 Failover involves two machines and a storage device such as Storage Area Network (SAN) or a Network
Attached Storage (NAS).
 The host running Primary server for JMS A, also runs the secondary server for JMS B and vice versa.
  This is done mainly to utilize the resources of both machines, so that the secondary server machine is not idle.
 If either machine fails, both JMS servers will still keep running, as long as the shared storage device is available

Site Failover - Case Study

 This diagram represents a complex implementation of failover, where an entire site can fail and services will still
not be disrupted.
 The two sites (Home Office and Main Office) can be geographically distant from each other, to protect against
natural disasters, such as earthquakes.
 In this implementation, the secondary servers are implemented on a different geographical location(site).
 Shared storage is local to a site, and shared storage is replicated between sites using third party software such as
Veritas Volume Manager.

Load-Balanced EMS Connections

Load balancing is implemented in several ways.

 Connection load balancing allows a client to connect to the least busy server in the "cluster" of EMS servers that
have routed visibility to the same destination.
 EMS supports a mechanism for message processing load balancing. For non-exclusive queues, multiple
consumers can process messages in a round robin fashion.
o Each message is only processed by one EMS consumer. If you have routed queues setup, you can do
both load balanced connections and load balanced processing of messages, both of which will solve
different performance issues.

EMS load balanced connections are configured using routes and connection factories in the EMS servers. No hardware or
application software need to be modified.

 Open a new terminal and enter the command as shown or copy it from the code snippet to restore the original
configuration files to config directory
 Close the terminal window
 Edit the main tibemsd.conf file to enable routing
o Open a new terminal and enter the commands as shown or copy them from code snippet
o Update the parameters server and routing
o Save and close the file
 Next, edit the route configuration file
o In the same terminal, enter the commands as shown or copy them from code snippet
o Add the parameters as shown at the end of the file
o [EMS-SERVER2] (should be there by default)
o url = tcp://7144 (change the default port number)
o zone_name = default_mhop_zone
o zone_type = mhop
o Save and close the file
 Now, edit the factories.conf file
o In the same terminal, enter the commands as shown or copy them from code snippet
o Add the parameters as shown at the end of the file
o [LBTopicConnectionFactory]
o url = tcp://7222|tcp://7144
o metric = connections
o [LBQueueConnectionFactory]
o url = tcp://7222|tcp://7144
o metric = connections
 o Save and close the file

#2
Configure Backup Server for Load Balancing
Play Video

 Create a directory for the data storage files of the load balanced server
o In the same terminal, enter the commands as shown or copy them from code snippet
o Enter the commands as shown to change the owner of the datastore-2 folder
 Next, copy datastore files from original datastore directory to datastore-2 directory
o In the same terminal, enter the commands as shown or copy them from code snippet
o Enter the commands as shown to change the owner of the datastore files in datastore-2 folder
o Use file browser and navigate to /opt/tibco/ems/8.5/samples/config/LB/datastore-2
o Verify the datastore files are copied
 Now, copy configuration files from config folder to LB folder
o In the same terminal, enter the commands as shown or copy them from code snippet
o Enter the commands as shown or copy them from code snippet to grant read/write permission to the
conf files

#3
Update Configuration Files for Backup Server
Play Video

 Update routes configuration for the backup server

o In the same terminal, enter the commands as shown or copy them from code snippet to edit the
routes.conf file
o Delete the existing route entry for EMS-SERVER 2
o Add the following lines as shown at the end of the file:
o [EMS-SERVER1]
o url = tcp://7222
o zone_name = default_mhop_zone
o zone_type = mhop
o Save and close the file
 Next, update the tibemsd.conf file for backup server
o In the same terminal, enter the commands as shown or copy them from code snippet to edit the
tibemsd.conf file
o Set the parameters as shown:
o server = EMS-SERVER2 (around line 26)
o listen = tcp://7144 (around line 81)
o routing = enabled (around line 95)
o Update the parameter for persistent messages as shown
o store = /opt/tibco/ems/8.5/samples/config/LB/datastore-2
o Update logfile parameter
o logfile = /opt/tibco/ems/8.5/samples/config/LB/datastore-2/logfile
o Save and close the file
 This completes the exercise Code Snippets
#Restore the original configuration files to config directory
sudo cp /home/tibco/Lab_Files/Original/*.conf
/opt/tibco/ems/8.5/samples/config/
Enter password: TIBCO7222
#Edit the main tibemsd.conf file
cd /$EMS_HOME/samples/config
sudo gedit tibemsd.conf
password: TIBCO7222

#Edit the route configuration file

sudo gedit routes.conf
password: TIBCO7222

#Edit the factories.conf file

sudo gedit factories.conf
password: TIBCO7222

#Create a directory for the data storage files

sudo mkdir LB
password: TIBCO7222
cd $EMS_HOME/samples/config/LB
sudo mkdir datastore-2

#Change the owner of datastore-2 folder

sudo chown tibco:tibco datastore-2

#Copy datastore files to datastore-2 folder

sudo cp $EMS_HOME/samples/config/datastore/*
$EMS_HOME/samples/config/LB/datastore-2
password: TIBCO7222

#Change the owner of datastore files in datastore-2 folder

cd $EMS_HOME/samples/config/LB/datastore-2
sudo chown tibco:tibco async-msgs.db sync-msgs.db meta.db

#Copy configuration files from config folder to LB folder.

sudo cp $EMS_HOME/samples/config/*.conf $EMS_HOME/samples/config/LB
password: TIBCO7222

#Grant read/write permission to the .conf files

cd $EMS_HOME/samples/config/LB
sudo chmod a+rwx *.conf

#Update routes configuration for the backup server

cd $EMS_HOME/samples/config/LB
sudo gedit routes.conf
password: TIBCO7222

#Update the tibemsd.conf configuration for the backup server.

sudo gedit tibemsd.conf
password: TIBCO7222
Lab E Exercise 2
Test Load Balancing
Play Video

In this exercise test the load balanced server pair.

During the message transfer, verify that both the PRIMARY and SECONDARY servers are sharing the load supporting
several JMS topic publishers.
 START
#1
Start the two Load Balanced Servers
Play Video

 Open a new terminal, name it as Primary Server, and enter the commands as shown or copy them from the code
snippet to start the primary server
 Open another terminal tab and name it as Secondary Server
o
o Enter the commands as shown or copy them from the code snippet to start secondary server
o Verify that both servers are active
o Note that the Secondary server acknowledges accepting the route from the Primary, and the Primary
reports it is connected to the Secondary

#2
Launch the Admin Tool and Multiple JMS Topic
Publishers
Play Video

 Open a new terminal window and run the commands as shown or copy them from the code snippet
 Several terminals open; the front two are the Admin tools for their respective servers
o Press <Enter> in each Admin tool terminal to connect
 There are six tibjmsMsg Producer repeatedly sending messages
o Their (client) connections are distributed between the two servers; three are handled by the primary
server (7222) and the other three by the secondary server (7144)
 Note that each topic publisher will send 99 messages. After that rerun the clients to continue testing


#3
Verify Client Connection Load Balancing Between the
two Servers
Play Video

 Go to the terminal titled Primary Admin: 7222 and issue the command show connections
 Go to the terminal titled Secondary Admin: 7144 and issue the command show connections
 Observe some clients are connected to the primary server, while others are connected to the secondary server
because they are being load balanced
 Analysis: The Enterprise Message Service server uses one of the two metric options for load balancing. By
default, it uses connections i.e. connect to the server with the fewest client connections. The alternative is
byte_rate i.e. connect to the server with the lowest byte rate. Byte rate includes both inbound and outbound data.
 Shutdown the servers (<Ctrl+c>) and close all the terminals when done with exploring
 Open a new terminal window and enter the commands as shown or copy them from code snippet to save the
updated config files
o Close the terminal
 This completes the exercise


Code Snippets
#Start the primary server
cd /home/tibco/Scripts
./start-ems-server.sh

#Start the secondary server

cd $EMS_HOME/samples/config/LB
$EMS_HOME/bin/tibemsd64 -config tibemsd.conf

#Launch the Admin tool and multiple JMS topic publishers

cd /home/tibco/Lab_Files/Export/LabE/Scripts
./TEST_LoadBalServers.sh

#Backup the configuration files

sudo cp -r /opt/tibco/ems/8.5/samples/config/*
/home/tibco/Lab_Files/Export/LabE
Enter password: TIBCO7222

6.Monitoring the TIBCO Enterprise Message Service™

Server
Monitor Enterprise Message Service™
Various ways to monitor Enterprise Message Service™ are:

 Trace messages and server activities: These are written to a log file or the console
 Server events: Published as messages
 Server statistics: Administration tool command
 TIBCO Hawk: Built-in Hawk microagent

Trace Server Activities

Tracing of server events can be enabled on the Enterprise Message Service™ server. There are several classes of data for
which the server can provide tracing services, including: Access Control, Administration and Routing. These events also
provide information about activities performed on or by the server, or the messages can provide warnings in the event of
failures or illegal actions.

This data is be sent to the console or logged to a file, or both. Tracing is configured in the following ways:

 By configuring the log_trace and/or console_trace parameters in the tibemsd.conf file

 By specifying the -trace option when starting the server
 By using the set server command when the server is running

Server Tracing and Trace Messages

 Parameters used to trace server events and messages are log_trace and console_trace. These parameters are used
to configure the types of messages that needs to go to the log file and to the console. Note that when trace
messages are to be sent to a log file, the logfile configuration parameter must also be configured. If log_trace is
specified, and the logfile configuration parameter is not set to a valid file, the tracing options are stored, but they
are not used until the server is started with a valid log file.
  Fine-grain control capabilities are available for tracing that can be enabled to monitor the Enterprise Message
Service™ server. There are over 20 server trace options available. Few tracing options like, DEFAULT,
ADMIN, ACL, etc., are shown in the slide. DEFAULT option sets the trace options to the default set. ACL
option prints a message when a user attempts to perform an unauthorized action. For detailed information of
other tracing options refer TIBCO Enterprise Message Service™ User's Guide.
 The examples in the slide shows the use of tracing parameters and options.

In addition to other server activity, you can trace messages as they are processed.

 Trace entries for messages are only generated for destinations or messages that specify tracing should be
performed. For destinations, specify the trace property to enable the generation of trace messages.
 For individual messages, the JMS_TIBCO_MSG_TRACE property specifies that tracing should be performed
for this message, regardless of the destination settings.
 Message trace entries can be output to either the console or the log.

Message Tracing Options

 Set server tracing option the MSG or DEFAULT trace option on the console or the log before you can view trace
entries for messages. The MSG trace option specifies that message trace entries should be displayed, and the
DEFAULT trace option includes the MSG option. The tracing property on either destinations or messages must
be set.
 The trace property on a destination specifies that trace entries are generated for that destination. This property
can optionally be specified as trace=body. Setting trace without the body option specifies that only the message
sequence and message ID are included in the trace message.

If message tracing is enabled, a trace entry is output when:

 messages are received into a destination

 messages are sent to consumers
 messages are imported or exported to/from an external system
 messages are acknowledged
 messages are sent across a destination bridge
 messages are routed

The JMS_TIBCO_MSG_TRACE property set for a message specifies that trace entries are generated for the message as it
is processed, regardless of whether the trace property is set for any destinations the message passes through. Trace
messages are generated for the message when it is sent by the producer and when it is received by the consumer.
Configure the Log File
The log file is specified in tibemsd.conf file. Following parameters are configured in the file:

 The logfile configuration parameter in tibemsd.conf controls the location and the name of the log file.
 You can specify that the log file should be backed up and emptied after it reaches a maximum size. This allows
you to rotate the log file and ensure that the log file does not grow boundlessly. The logfile_max_size
configuration parameter allows to specify the maximum size of the current log file. Set the parameter to 0 to
specify no limit. Use KB, MB, or GB unit.
 Once the log file reaches its maximum size, it is copied to a file with the same name as the current log file except
a sequence number is appended to the name of the backup file, for example, server.log.1, server.log.2, etc.
Logfile_max_count parameter specifies the maximum number of log files to keep, including the current log file.

You can also dynamically force the log file to be backed up and truncated using the rotatelog command in tibemsadmin.
Server Events
 The TIBCO Enterprise Message Service server can publish topic messages for several system events.
 For example, the server can publish a message when users connect or disconnect.
 System event messages contain details about the event stored in properties of the message.
 Monitor topics are created and maintained by the server. These topics are not listed in the topics.conf file and
users cannot create them.
 Following are the features of system monitor topics:
 They contain sensitive internal system information.
 Authentication and permissions are always needed for clients to access a monitor topic.
 Topic subscribers can use message selectors to filter the monitor messages so that application receives
only the messages it is interested in.
 All system event topic names begin with $sys.monitor. The remainder of the name is the event class followed by
the event.
 For example, the server publishes a message to the topic $sys.monitor.connection.disconnect whenever
a client disconnects from the server. The rest of the name is the event class followed by the event.
 Note that server only generates messages for monitor topics that currently have subscribers. Generating monitor
topic message consumes system resources.
 System performance is affected by the number of subscribers for monitor topics as well as the
frequency of messages for those topics.
 For production systems, monitoring all events may have an adverse effect on system performance.
 Subscriptions to monitor topics in production systems should always be limited to specific monitor
topics or wildcard subscriptions to specific classes of monitor topics that are required.
 Using message selectors to limit monitor messages can improve performance slightly.

View System Monitor Topics

 Monitor topics are just like any other topic. To view these topics, create a client application that subscribes to the
desired topics. You can create different applications that subscribe to different monitor topics, or you can create
one application that subscribes to all desired monitor topics.
 As monitor topics contain potentially sensitive system information, authentication and permissions are always
checked when clients access a monitor topic. That is, even if authentication for the server is disabled, clients are
not able to access monitor topics unless they have logged in with a valid username and password and the user has
permission to view the desired topic.
 The admin user and members of the $admin group have permission to perform any server action, including
subscribing to monitor topics. All other users must be explicitly granted permission to view monitor topics
before the user can successfully create subscribers for monitor topics. System event topics allows to create
wildcard subscriptions for all events of a certain class. The example in the slide shows the command to grant
permission to a user to receive messages whenever clients connect or disconnect.

Monitor Server Statistics

 The TIBCO Enterprise Message Service server allows to track incoming and outgoing message volume, message
size, and message statistics for the server overall as well as for each producer, consumer, or route. You can
configure the type of statistics collected, the interval for computing averages, and amount of detail for each type.
 Statistics tracking can be set in the server’s configuration file. The configuration can be dynamically changed by
using the administration tool or the administration APIs.
 There are basically two types of statics that are collected, namely, overall statistics and detailed statistics.
 The server always collects the overall server statistics.
 Overall statistics is always enabled and includes the rate of inbound and outbound messages (expressed
as number of messages per second), message memory usage, disk storage usage, and the number of
destinations, connections, and durable subscriptions.
  Detailed statistics, on the other hand, provides detailed statistics for individual producers, consumers,
destinations and routes.

Overall and Detailed Statistics

Overall statistics:

 The default interval for collecting overall server statistics is 1 second.

 The server_rate_interval configuration parameter controls the collection interval for server statistics.
 The parameter can be set in the configuration file or dynamically using the set server command.
 This parameter can only be set to positive integers greater than zero. Collecting overall statistics consumes no
system resources, hence these statistics are always available. You can view overall server statistics by executing
the show server admin command or by using the TIBCO Enterprise Message Service admin API.

Detailed Statistics:

 In some situations, the default statistic gathering may not be sufficient. For example, if a topic subscriber
subscribes to wildcard topics, the total statistics for all topics that match the wildcard are kept. You may wish to
get further detail in this case and track the statistics for each actual topic the subscriber receives.

The following situations can require detailed statistic gathering:

 Topic subscribers that subscribe to wildcard topics

 Message producers that do not specify a destination when they are created
 These message producers can produce messages for any destination, and the destination name isspecified when a
message is sent
 Routes can have incoming and outgoing messages on many different topics

Following are the parameters to enable detailed statistics gathering:

 statistics: Enables or disables the statistics collection.

 detailed_statistics: Enables detailed statistics to the type of statistics required to receive. This parameter can have
values, like, NONE, CONSUMERS, PRODUCERS, or ROUTES.
 statistics_cleanup_interval: Controls how long the detailed statistics are kept. Default value is 15 seconds.
 max_stat_memory: Controls the amount of memory used by detailed statistics. Default value is 0.

All these parameters are set either in configuration file or dynamically with set server admin command.
Display Detailed Statistics
 When statistics collection is enabled, you can view statistics for producers, consumers, routes, and destinations
using the show stat command in the administration tool.
 The show stat command allows you to filter the statistics based on destination name, username, connection ID,
or any combination of criteria. Statistics for consumers, producers, destinations or routes can be viewed. Show
stat command options are shown in the slide.
 You can optionally specify the ‘total’ keyword to retrieve only the total statistics i.e., total number of messages
and total message size (this suppresses the detailed output). The ‘wide’ keyword is used when displaying
statistics for destinations or routes. This specifies that inbound and outbound message statistics should be
displayed on the same line (the line can be 100 characters or more).
 The image in the slide shows an example of consumer statistics.

Monitor Server Message Storage

Server’s database can be monitored by using the following admin commands:

 show db: Summarizes the usage of just async-msgs.db, sync-msgs.db, or both, if you omit the parameter. The
image shown in the slide displays the console output for show db command.
 show stores: Lists the persistent stores in use.
 show store store-name: Shows the details of a specific store. This command is used to get details about either
file-based store or database store.

Explore Server Monitoring

Explore Server Monitoring
Play Video

In this exercise, explore the Enterprise Message Service™ monitoring utility tibemsmonitor that is provided with the
TIBCO Enterprise Message Service™ product.

Note that this utility is not designed for use in a production environment.
START
#1
Start the Monitoring Tool as Admin User
Play Video

 Open a new terminal and enter the command as shown or copy it from the code snippet to restore the original
configuration files to config directory
o Close the terminal window
 Open a new terminal, name it as EMS Server, and enter the commands as shown or copy them from code
snippet to start the server
 Open a new terminal, name it as Monitoring and issue the command as shown to view help information for
tibemsmonitoring utility
o The utility’s help screen is displayed, providing the syntax and parameter descriptions for monitoring
server activities
 Now, from the same terminal, enter the command as shown or copy it from the code snippet to start the
monitoring tool
o When prompted for the password, press <Enter>
o Note that no password is required
o If the tool is not connected, ensure that the command entered is correct, and the server is running

#2
Perform Activities in the Admin Tool and Observe
Tracing Messages in Monitoring Tool
Play Video

 Open a new terminal and name it as Admin

 Start the Admin tool and connect to server as the admin user
o Use the commands as shown or copy them from code snippet
 Enter the commands as shown or copy them from code snippet to
o Create a new destination object (topic or queue),
o Create a new user or group object,
o Modify an existing destination object
  Switch to Monitoring terminal and observe that the admin tool activities are traced and displayed by the
monitoring tool
 Run the monitor utility with parameter -m "connection.>" to monitor only connect and disconnect events
 Similarly, experiment with different combinations of parameters in the tibemsmonitor utility

 This completes the exercise Code Snippets

#Restore the original configuration files to config directory
sudo cp /home/tibco/Lab_Files/Original/*.conf
/opt/tibco/ems/8.5/samples/config/
Enter password: TIBCO7222

#Start the EMS server

cd /home/tibco/Scripts
./start-ems-server.sh

#View help information for tibemsmonitor utility

tibemsmonitor -help

#Start the monitoring tool as the admin user

tibemsmonitor -server tcp://localhost:7222 -user admin -m ">"

#Start the Admin tool and connect to server as the admin user
cd /$EMS_HOME/bin
tibemsadmin
connect (press <Enter> for Login name and Password)

#Create a new destination object

create topic TOPIC_NEW

#Create a new user or group object

create user TESTUSER

#Modify an existing destination object

grant topic TOPIC_NEW TESTUSER publish, subscribe

#Run the tibemsmonitor utility with parameter -m "connection.>"

tibemsmonitor -server tcp://localhost:7222 -user admin -m "connection.>"
Lab F Exercise 2
Test Server Monitoring as Non-Admin User
Play Video
In this exercise, try to use the tibemsmonitor monitoring utility as a non-admin user.
START
#1
Start the Monitoring Utility as Non-Admin User
Play Video

 From the terminal named Admin enter the command as shown or copy it from code snippet to create a new user
 From the Adminterminal, type the command show config
o Under the # settings heading, verify the line: authorization = disabled
o If it is enabled, then disable it using the command set server authorization=disabled
 From the terminal named Monitoring, disconnect tibemsmonitor as admin user (use <Ctrl+c>) and start it again
as labuser using the command shown
o If prompted for a password, press <Enter>
 o The exception error as shown should be received

#2
Monitor System Events using Monitoring Tool
Play Video

 From Admin tool, type the command as shown or copy it from code snippet to grant subscription for a topic to
the labuser
 Start tibemsmonitor using the command as shown
o This time you should be able to successfully monitor all system events while logged in
to tibemsmonitor as labuser
 From Admin tool, enter the command create queue myqueue to create a new queue
o Observe output in monitoring tool
 Close the monitoring terminal
 This completes the exercise

Code Snippets
#Create a new user
create user labuser

#Start tibemsmonitor as labuser

tibemsmonitor -server tcp://localhost:7222 -user labuser -m ">"

#Grant subscription permissions for topic "$sys.monitor.>" to the labuser

grant topic $sys.monitor.> labuser subscribe

#Create a queue
create queue myqueue
Lab F Exercise 3
View Server Statistics
Play Video
In this exercise, view the server statistics using the Administration tool.
START
#1
Set Statistics Parameters
Play Video

 Use the Administration tool to verify that the statistics parameter is enabled
o From the terminal named Admin, enter the command show config
o Under the statistics settings heading, verify the line: statistics = enabled
o Note that the statistics parameter allows to globally enable and disable statistics gathering.
 From the same terminal, enter the commands as shown or copy from code snippet to create three topics
 Next, enter the command as shown or copy it from code snippet to set the detailed statistics for the consumer
object
o Note that this command enables the detailed statistics for topic subscribers with wildcard topic names
 #2
Run the Producer Client
Play Video

 Open a new terminal and name it as Producer

 Type the command as shown or copy it from code snippet to run the producer
o This producer sends 10,000 messages
 Next, display the statistics for consumers
o From the Admin terminal, enter the command show stat consumers
o The show stat command allows to filter the statistics based on destination name, user name, connection
ID or any combination of criteria
o The output shows no statistics for the consumer, as the consumer is not active

#3
Run the Consumer Client
Play Video

 Open a new terminal and name it as Consumer

 Enter the commands as shown or copy them from code snippet to run the consumer
 Switch to Producer terminal and run the producer three times to produce messages for all three topics created
earlier
 Switch to Consumer terminal and verify the subscriber should now start receiving all the messages
 Now, check the statistics for the consumers
o From the Admin terminal, enter the command show stat consumers
o Observe the messages consumed by the topics and rate of message consumption
o Enter the command show config
 Note that the statistics_cleanup_interval is set to 30. This specifies how long the server should keep detailed
statistics if the destination has no activity. When the specified interval is reached, statistics for destinations with
no activity are deleted.
o After 30 seconds, check the consumer’s statistics again
o No statistics for destinations is displayed
o Issue the command as shown or copy # 4

View Overall Server Statistics

Play Video

 Stop the subscriber from Consumer terminal (use <Ctrl+c>)

 From Admin terminal issue show stat consumers command
o No statistics is shown as the consumer is no longer active
 From the Admin terminal, issue the show server command to view overall server statistics
 This command displays the overall server statistics which includes the rate of inbound and outbound messages,
message memory usage, disk storage usage and the number of destinations, connections and durable
subscriptions.
 Shutdown the clients and the server and close all terminals
 Open a new terminal window and enter the command as shown or copy them from code snippet to save the
updated config files
 Close the terminal
 This completes the exercise

Code Snippets
#Create three new users
create topic stats.topic1
create topic stats.topic2
create topic stats.topic3

#Set the detailed statistics for the consumer object.

set server detailed_statistics=consumers

#Run the tibjmsMsgProducerPerf client

cd $EMS_HOME/samples/java
source setup.sh
java tibjmsMsgProducerPerf -topic stats.topic1

#Display the statistics for consumers.

show stat consumers

#Run the tibjmsMsgConsumer with wildcard topic names

cd $EMS_HOME/samples/java
source setup.sh
java tibjmsMsgConsumer -topic stats.*

#run the producer three times to produce messages for all three topics created
java tibjmsMsgProducerPerf -topic stats.topic1
java tibjmsMsgProducerPerf -topic stats.topic2
java tibjmsMsgProducerPerf -topic stats.topic3

#set the statistics_cleanup_interval

set server statistics_cleanup_interval=0

#backup config files

sudo cp -r /opt/tibco/ems/8.5/samples/config/*
/home/tibco/Lab_Files/Export/LabF
Enter password: TIBCO7222

TIBCO Enterprise Message Service™ Central

Administration Overview
Central Administration Introduction
 Enterprise Message Service Central Administration is a tool for centralized administration and deployment of
multiple servers.
 It provides ability to apply configuration changes to multiple servers or fault-tolerant pairs of servers from a
single, centralized location.
 The participating servers must use the configuration based on JSON (Java Script Object Notation) files.
 An Enterprise Message Service server configured by text-based *.conf files cannot be used for Central
Administration.
 Central Administration also provides a web-based graphical user interface to configure Enterprise Message
Service servers.
jSON Configuration vs. *.conf Files
 The Enterprise Message Service™ server can be configured either by using configuration stored in a set of text-
based *.conf configuration files, or by a single JSON file. The choice is mutually exclusive.
 A single JSON configuration file holds all the configuration settings for a single server or for a pair of fault
tolerant servers. The default name of the JSON-based configuration file is tibemsd.json. The utility
tibemsconf2json converts the existing text-based configuration to the JSON file configuration.
 Enterprise Message Service server can be managed by Central Administration only if it is started using a JSON
file

Central Administration Information Flow

The Central Administration Server connects to the running EMS Server and stores a snapshot of its configuration.

Central Administration Server’s data directory contains:

 Working directory: Stores the last configuration retrieved from the EMS Server. It also stores lock file if the
configuration is currently being edited via Web Interface.
 Deployment directory: Contains the details of each configuration that has been previously deployed to the EMS
Server.

Commands issued through the Central Administration web interface modifies the configuration files in these two
directories. Image in the slide shows the configuration information flow for each action performed through web interface.

 Lock & Edit enables the user to edit the configuration, and the edits are saved in the lock file stored in working
directory.
 Save action saves configuration changes made to the EMS server through the web interface to the lock file.
 Deploy action takes the configuration lock file from the working directory, and deploys it to the EMS server. If
the deployment succeeds, the lock file is copied to the deployment directory for the current deployment and to
the working file for the EMS server.
 Refresh action retrieves the currently deployed configuration file from the running EMS server, and save that
file in the working directory.

jAAS Authentication and SSL

If JAAS authentication is configured, JAAS credentials are required to log in via Web interface. The same credentials are
used when Central Administration Server logs in to the Enterprise Message Service server. If not, the user admin is used to
authenticate with the server.

If SSL is configured, all Enterprise Message Service servers managed by the same Central Administration server must
use the same configuration scenario. There are two supported configuration scenarios:

 No parameters are set in the Central Administration Server (EMS Server does not require an identity certificate
from the Central Administration Server)
 Central Administration Server is configured to supply identity certificate/password (EMS Server requires an
identity certificate)
 .

Central Administration Web Interface

Various pages are available in Central Administration web interface:

 Server List page: It is the home page of the web interface. It displays the complete list of Enterprise Message
Service servers managed by the Central Administration server.
 Server Overview page: This page is a gateway to all server configuration options. Contains set of links to the
properties pages, organized by following categories: Destinations, Connections, Server and Security.
 Deployments page: Provide details about every deployment executed from Central Administration server. From
this page you can revert to earlier deployment or delete a deployment history if needed.
 Property page: Each property page contains configuration details for a specific property type.

Web Interface Icons

Icons are used throughout the Central Administration web interface to give access to commonly used commands and tasks.
These icons are divided into two general categories, namely, command icons and manipulating icons.

Following command icons are available in the upper right corner of the web interface:

 Lock & Edit - Creates a modifiable copy of the configuration file, and stores it in the working directory. The
configuration file is locked so that only the current user can modify the file.
 Deploy - Deploys all the modified server configurations. Saves the modified configuration files of all the EMS
servers locked by the user to the working directory and packages them as a deployment. Then it sends the
deployment package to EMS servers and releases the locks upon successful deployment.
 Revert - Reverts all the modifications, stops editing, and releases all the locks.
 Refresh - Discards all the modification and retrieve the current configuration file from the Enterprise Message
Service server.
 Save - Saves modifications to the working directory. Central Administration frequently auto-saves modifications
to the working directory. This command forces a save.
 Download - Downloads the server’s JSON configuration file.

Manipulating icons available in web interface are: Add, Delete, View, Duplicate, and Undo.
Deploy Configuration
Deploy action deploys the every EMS server locked by the current user. Once the deploy command is given, the Central
Administration performs the following actions:

 Deploys the working copy of the JSON configuration file to the EMS server
 Updates the deployment archive with the new configuration
 Releases the lock on the EMS server and displays the deployments page

Deployment fails if there are any errors while connecting to and updating the EMS Server. If the failed deployment
involved multiple EMS servers and some deploy correctly while others fail, servers that did not deploy can attempt
redeployment later. The server lock file remains in its edited state.

You can use the option --keep-max-deployments to configure how many deployments to keep in your EMS Central
Administration server. When the maximum deployment is reached, the older configurations are removed.
Redeploy and Refresh
 Redeploy reverts all EMS servers deployed in the selected deployment. EMS servers that failed in the original
deployment are excluded from the redeployment.
  Redeploying updates the EMS server but does not affect the working directory or the lock file. As a result, the
working copy and lock files in Central Administration are out of sync with the running EMS server. To obtain
the current configuration, refresh the EMS server configuration.
 Refresh obtains the current configuration from the EMS server. If changes have been made to the EMS server
configuration using the Administration Tool, API calls, or by directly editing the configuration file, the Central
Administration server must be refreshed to retrieve these changes from the server

EMS Server with JSON Configuration

 An EMS server must be started in JSON mode to be able to participate in Central Administration.
 To convert a set of text-based configuration files into a single JSON configuration file, use the utility
tibemsconf2json.
 A fault tolerant pair shares the single JSON configuration file.
 Values for listen URL and ft_active are not shared by servers. secondary_logfile allows the servers to use
different logfiles. All other configuration settings are shared between the servers.

To start the fault tolerant pair:

 The primary EMS server starts as usual

 The command to start the secondary server contains the flag -secondary

In this exercise, explore the Enterprise Message Service™ monitoring utility tibemsmonitor that
is provided with the TIBCO Enterprise Message Service™ product.

Note that this utility is not designed for use in a production environment.

In this exercise, explore the Enterprise Message Service™ monitoring utility tibemsmonitor that is provided with the
TIBCO Enterprise Message Service™ product.

Note that this utility is not designed for use in a production environment.
START
#1
Start the Monitoring Tool as Admin User
Play Video

 Open a new terminal and enter the command as shown or copy it from the code snippet to restore the original
configuration files to config directory
o Close the terminal window
 Open a new terminal, name it as EMS Server, and enter the commands as shown or copy them from code
snippet to start the server
 Open a new terminal, name it as Monitoring and issue the command as shown to view help information for
tibemsmonitoring utility
o The utility’s help screen is displayed, providing the syntax and parameter descriptions for monitoring
server activities
 Now, from the same terminal, enter the command as shown or copy it from the code snippet to start the
monitoring tool
o When prompted for the password, press <Enter>
o Note that no password is required
 o If the tool is not connected, ensure that the command entered is correct, and the server is running

#2
Perform Activities in the Admin Tool and Observe
Tracing Messages in Monitoring Tool
Play Video

 Open a new terminal and name it as Admin

 Start the Admin tool and connect to server as the admin user
o Use the commands as shown or copy them from code snippet
 Enter the commands as shown or copy them from code snippet to
o Create a new destination object (topic or queue),
o Create a new user or group object,
o Modify an existing destination object
 Switch to Monitoring terminal and observe that the admin tool activities are traced and displayed by the
monitoring tool
 Run the monitor utility with parameter -m "connection.>" to monitor only connect and disconnect events
 Similarly, experiment with different combinations of parameters in the tibemsmonitor utility
 This completes the exercise

Code Snippets
#Restore the original configuration files to config directory
sudo cp /home/tibco/Lab_Files/Original/*.conf
/opt/tibco/ems/8.5/samples/config/
Enter password: TIBCO7222

#Start the EMS server

cd /home/tibco/Scripts
./start-ems-server.sh

#View help information for tibemsmonitor utility

tibemsmonitor -help

#Start the monitoring tool as the admin user

tibemsmonitor -server tcp://localhost:7222 -user admin -m ">"

#Start the Admin tool and connect to server as the admin user
cd /$EMS_HOME/bin
tibemsadmin
connect (press <Enter> for Login name and Password)

#Create a new destination object

create topic TOPIC_NEW

#Create a new user or group object

create user TESTUSER

#Modify an existing destination object

grant topic TOPIC_NEW TESTUSER publish, subscribe

#Run the tibemsmonitor utility with parameter -m "connection.>"

tibemsmonitor -server tcp://localhost:7222 -user admin -m "connection.>"
Lab F Exercise 2
Test Server Monitoring as Non-Admin User
Play Video
In this exercise, try to use the tibemsmonitor monitoring utility as a non-admin user.
START
#1
Start the Monitoring Utility as Non-Admin User
Play Video

 From the terminal named Admin enter the command as shown or copy it from code snippet to create a new user
 From the Adminterminal, type the command show config
o Under the # settings heading, verify the line: authorization = disabled
o If it is enabled, then disable it using the command set server authorization=disabled
 From the terminal named Monitoring, disconnect tibemsmonitor as admin user (use <Ctrl+c>) and start it again
as labuser using the command shown
o If prompted for a password, press <Enter>
o The exception error as shown should be received

#2
Monitor System Events using Monitoring Tool
Play Video

 From Admin tool, type the command as shown or copy it from code snippet to grant subscription for a topic to
the labuser
 Start tibemsmonitor using the command as shown
o This time you should be able to successfully monitor all system events while logged in
to tibemsmonitor as labuser
 From Admin tool, enter the command create queue myqueue to create a new queue
o Observe output in monitoring tool
 Close the monitoring terminal
 This completes the exercise

2
Code Snippets
#Create a new user
create user labuser

#Start tibemsmonitor as labuser

tibemsmonitor -server tcp://localhost:7222 -user labuser -m ">"

#Grant subscription permissions for topic "$sys.monitor.>" to the labuser

grant topic $sys.monitor.> labuser subscribe

#Create a queue
create queue myqueue
Lab F Exercise 3
View Server Statistics
Play Video
In this exercise, view the server statistics using the Administration tool.
START
#1
Set Statistics Parameters
Play Video

 Use the Administration tool to verify that the statistics parameter is enabled
o From the terminal named Admin, enter the command show config
o Under the statistics settings heading, verify the line: statistics = enabled
o Note that the statistics parameter allows to globally enable and disable statistics gathering.
 From the same terminal, enter the commands as shown or copy from code snippet to create three topics
 Next, enter the command as shown or copy it from code snippet to set the detailed statistics for the consumer
object
o Note that this command enables the detailed statistics for topic subscribers with wildcard topic names

#2
Run the Producer Client
Play Video

 Open a new terminal and name it as Producer

 Type the command as shown or copy it from code snippet to run the producer
o This producer sends 10,000 messages
 Next, display the statistics for consumers
o From the Admin terminal, enter the command show stat consumers
o The show stat command allows to filter the statistics based on destination name, user name, connection
ID or any combination of criteria
 o The output shows no statistics for the consumer, as the consumer is not active

#3
Run the Consumer Client
Play Video

 Open a new terminal and name it as Consumer

 Enter the commands as shown or copy them from code snippet to run the consumer
 Switch to Producer terminal and run the producer three times to produce messages for all three topics created
earlier
 Switch to Consumer terminal and verify the subscriber should now start receiving all the messages
 Now, check the statistics for the consumers
o From the Admin terminal, enter the command show stat consumers
o Observe the messages consumed by the topics and rate of message consumption
o Enter the command show config
 Note that the statistics_cleanup_interval is set to 30. This specifies how long the server should keep detailed
statistics if the destination has no activity. When the specified interval is reached, statistics for destinations with
no activity are deleted.
o After 30 seconds, check the consumer’s statistics again
o No statistics for destinations is displayed
o Issue the command as shown or copy it from the code snippet to set the statistics_cleanup_interval

#4
View Overall Server Statistics
Play Video

 Stop the subscriber from Consumer terminal (use <Ctrl+c>)

 From Admin terminal issue show stat consumers command
o No statistics is shown as the consumer is no longer active
 From the Admin terminal, issue the show server command to view overall server statistics
  This command displays the overall server statistics which includes the rate of inbound and outbound messages,
message memory usage, disk storage usage and the number of destinations, connections and durable
subscriptions.
 Shutdown the clients and the server and close all terminals
 Open a new terminal window and enter the command as shown or copy them from code snippet to save the
updated config files
 Close the terminal
 This completes the exercise

Code Snippets
#Create three new users
create topic stats.topic1
create topic stats.topic2
create topic stats.topic3

#Set the detailed statistics for the consumer object.

set server detailed_statistics=consumers

#Run the tibjmsMsgProducerPerf client

cd $EMS_HOME/samples/java
source setup.sh
java tibjmsMsgProducerPerf -topic stats.topic1

#Display the statistics for consumers.

show stat consumers

#Run the tibjmsMsgConsumer with wildcard topic names

cd $EMS_HOME/samples/java
source setup.sh
java tibjmsMsgConsumer -topic stats.*

#run the producer three times to produce messages for all three topics created
java tibjmsMsgProducerPerf -topic stats.topic1
java tibjmsMsgProducerPerf -topic stats.topic2
java tibjmsMsgProducerPerf -topic stats.topic3

#set the statistics_cleanup_interval

set server statistics_cleanup_interval=0

#backup config files

sudo cp -r /opt/tibco/ems/8.5/samples/config/*
/home/tibco/Lab_Files/Export/LabF
Enter password: TIBCO7222
Unit 7: Lecture

TIBCO FTL® Server and

TIBCO FTL Architecture

 An FTL server is the consolidated server executable or any process that executes it. An FTL server consolidates
and manages the following services into one server process: realm service, persistence service, transport bridge
service, group service, authentication service, and eFTL service.
 Management includes starting a service and automatically restarting it when it is not running. A set of server
processes coordinate to provide fault-tolerant services. The realm service is the central repository for
configuration data required by the FTL client processes, which include FTL application programs and services.
This configuration data is called the realm definition. The detailed description of FTL services are explained in
the coming slides.
 Applications provide a logical definition for publishing data or subscribing to data. It defines the used messaging
formats and transports. Programs send messages using publisher objects and receive messages using subscriber
objects. Applications obtain operational metadata from a realm service.
 The realm service funnels operational metrics from application clients to external monitoring points. For low
latency, messages travel directly between peer application programs, rather than through a store-and-forward
server. Applications communicate directly from endpoint to endpoint through transports. More than one transport
can be defined per applications.

TIBCO FTL Services

Each service is a module that runs within an FTL server. Each service implements part of the functionality available in
TIBCO FTL.

Following are the available FTL services:

 Realm Service: A realm is a namespace that defines resources and configurations available to application
programs.
o The realm service maintains the realm definition, distributes it to clients, and collates operating metrics
from clients.
o Every FTL client uses realm service to load metadata at startup. This service distributes to each client a
version of the realm definition that is tailored for that specific client.
o The client process stores this tailored realm definition in a realm object. Client applications and services
send their operating metrics to the realm service.
 Authentication Service: The realm service can authenticate users against a separate authentication service or an
internal authentication service.
  Transport Bridge Service: Bridge service forward messages between two endpoints.
 Persistence Service: Persistence services store messages for durable subscribers.
 eFTL Service: eFTL services forward messages between eFTL clients and FTL clients.

FTL Server Executable

Administrators use tibftlserver, the FTL server command line executable, to start an FTL server process. It uses the
following arguments:

 -h: The FTL server prints a usage message summarizing its command line parameters.
 -c: Specifies the configuration file path. The FTL server reads the configuration file at the given path.
 -n: This parameter designates the name of the FTL server and selects one of the core servers.
 --init-security: The FTL server uses the password_specifier argument to secure the keystore file. When present,
the FTL server generates new TLS data, and then immediately exits.
 --init-auth-only: The FTL server generates new authentication data, and then immediately exits. If the FTL server
detects existing authentication files, it does not generate a new one. However, the server does not decrypt or
inspect existing files.

FTL Server Configuration

 You can specify all the values for a localized cluster of cooperating FTL servers, along with the services they
provide in a single configuration file in YAML format.
 Location of the configuration file is as given in the slide.
 There are multiple sample configuration files present in the YAML folder, for example, tibftlserver_standalone,
tibeftlserver_eftl, etc. You can modify and use these files as per your requirement.
 The image on the slide shows an example of a configuration file.

Configuration File Sections

There are three sections in the FTL configuration file; namely; globals, services, and servers.

 Globals section contain values that are mandatory and directly affect the operation of the FTLservers. The
globals section can contain any of the following items:
o Key/value pairs that directly affect the operation of FTL servers.
o Key/value pairs that all applicable services can inherit. You can override these values in service
sections, or in the individual service sections within any server section.
 Services section is optional and this section contains a section for each type of service (for example, realm,
persistence, bridge, eFTL). It can also contain an FTL section with parameters that apply to the FTL server as a
whole, but are not inherited by other services or servers. Within each service section, you can specify key/value
pairs that apply through inheritance to all instances of a service in any FTL server. These values override values
inherited from the globals section. Specifying a service section does not imply that every FTL server provides
that service.
 The servers section contains a map of the FTL servers you are configuring. Each item in the map pairs a server
name with a list of services that the server provides. The map must contain an item configuring each core server,
and may also include optional items configuring auxiliary servers. For each server, you need to configure a list of
services that server provides. An FTL server provides a service if and only if the service is configured at this
level. Within each server section, you may override key/value pairs inherited from the global section or a global
service section. You can omit the servers section, if the configuration file specifies only one core server, and
specifies its extended server name with host and port.

Configuration Parameters
  The table in the slide enlists few of the configuration parameters in the globals and services section in the
configuration file.
 Spare some time and go through the table.
 For other parameters, refer TIBCO FTL Administration guide.

FTL Server as Message Broker

 FTL server can be implemented as a message broker, an intermediate store-and-forward service between
publishers and subscribers. When an FTL server runs without specifying any configuration file, it automatically
operates as message broker.
 In message broker pattern, message travels in two hops, from the publisher to the FTL server (message broker),
and then from FTL server to subscribers. When three servers run without any configuration file, they
automatically join together to operate as message broker.
 The realm defines a default application which uses the default non-persistent store and the dynamic standard
durable template named ftl.pubsub.template. Any application definition can specify a server-defined transport,
Server, which automatically connects with the persistence services of the message broker. When application
programs interact with the message broker, its default behavior uses a non-persistent store and standard durables.
 Sample applications are available in the scripts folder under samples folder. ftlstart command runs the server
with default values. The example in the slide shows the use of ftlstart command to run the FTL server as message
broker.

FTL Admin Utility

tibftladmin is the FTL server administration utility used to manage FTL server. It uses the following arguments:

 -ftls: Administer the FTL server at this location.

 -dr: Write the realm definition to a JSON file at the given path.
 -ur: Update the realm definition from JSON file at the given path. If a realm definition already exists, the utility
replaces the old realm definition with the new definition. This command is available only for a primary server.
 -b: Write a backup copy of the realm database.
 -st: Get the status of the FTL server and its clients.
 -x: Stop the FTL server process and all the services it provides. This command does not wait for confirmation
that the server has stopped.

Configure and Start FTL Server

Pause
Loaded: 100.00%
Remaining Time -0:06

1x
Playback Rate
Picture-in-PictureFullscreen
Mute
In this exercise, configure the TIBCO FTL server using yaml configuration file and run the FTL server using the same
configuration.
START
#1
Configure FTL Server using YAML Configuration File
Play Video
  Create folder to store FTL server data
o Open a new terminal window and name its title as FTL Server
o Enter the commands as shown or copy from code snippet to create data folder
 Next, configure FTL server using YAML configuration file
o From the same terminal, enter the command as shown or copy from code snippet to open and edit the
configuration file
 Configuration file opens in text editor
o Verify the following default configurations:
o Globals section: 3 core servers
o Services section: realm and data location
o Servers section: All 3 servers with default realm and eftl service
o Edit the configuration file as shown
o Delete or comment the configurations for ftlserver2 and ftlserver3 from globals and servers
section
o Enter the path for data parameter (The FTL server stores its working data files in this path location.
Ensure that this folder is present at the given path, if not create the folder.)
o Save and close the file
 Note that YAML coding is very sensitive to spaces and indentation
 Therefore, correctly indent, use spaces and new lines to avoid any errors while making any entries in the YAML
files

#2
Start the FTL Server and Access it Using a Browser
Play Video

 From the same terminal, enter the commands as shown or copy from code snippet to start the FTL server
o This command starts the FTL server process and its configured services
o You can minimize the terminal window, but do not close it
 Now, access FTL server using a browser window and view application loaded by default
o Open Firefox Browser
o Enter the FTL server URL
o Click SIGN IN with User Id anyone
o Verify Applications tab is displayed with the default application as shown

3
 4

#3
Start a New Receiver Client Application
Play Video

 Minimize the Firefox browser

 Open a new terminal and rename its title as Receive Messages
 Enter the commands as shown to view the available options for receiver program
 Enter the command as shown or copy from code snippet to start the receiver program
o Observe the command throws an error stating Realm not responding
o The error indicates that the program is expecting an application named tibrecv to be defined
o So, re-run the program and override the application name
 Stop the program using <Ctrl+c> keyboard buttons
 Start the receiver program again using the existing configuration as shown
o Verify that the program starts up and is waiting for messages
 tibrecvex is an enhanced version of tibrecv that provides options to vary application name, message count and so
on

#4
Send Messages and Verify the Messages are Received
Play Video

 Open a new tab in the Receive Messages terminal and name it as Send Messages
 Examine the options for the message sender program as shown
 Run the sender program with the updated application and endpoint names as shown
 Go back to Receive Messages terminal and observe the client received the message
 Both the programs are terminated after one message
 Analysis: This shows that the application definition in the FTL server can be used by a properly configured
client program. The client program locates the definition of the application and sends and receives messages
using the transports and endpoints defined for that application. Application definition (metadata) and clients are
truly decoupled.
 Open a new terminal and enter the commands as shown or copy from the code snippet to stop the FTL server
 Close all the terminals and Firefox browser window
 Open a new terminal and enter the command as shown or copy from the code snippet to take backup of the
configuration file
o Close the terminal window
 This completes the exercise

1
 2

Code Snippets
#create data folder
cd /opt/tibco/ftl/6.4/samples/yaml/eftl
sudo mkdir data
password: TIBCO7222

#open and edit the configuration file

sudo gedit tibftlserver_eftl.yaml
password: TIBCO7222

#Start the FTL server

cd /opt/tibco/ftl/6.4/bin
sudo ./tibftlserver -c
/opt/tibco/ftl/6.4/samples/yaml/eftl/tibftlserver_eftl.yaml -n ftlserver1
ftlserver1@localhost:8585
password: TIBCO7222

#view the available options for receiver program

cd /opt/tibco/ftl/6.4/samples/bin/advanced
./tibrecvex -h

#start the receiver program

./tibrecvex http://localhost:8585

#Start the receiver program using the existing configuration

./tibrecvex -a default -e default http://localhost:8585

#view the available options for sender program

./tibsendex -h

#Run the sender program with the updated application/endpoint names

./tibsendex -a default -e default http://localhost:8585

#Stop FTL server

cd /opt/tibco/ftl/6.4/bin
./tibftladmin -x --ftlserver http://localhost:8585

#Backup config files

sudo cp /opt/tibco/ftl/6.4/samples/yaml/eftl/*.yaml
/home/tibco/Lab_Files/Export/LabH
password: TIBCO7222
Start the FTL Server and Access it Using a Browser
Play Video

 From the same terminal, enter the commands as shown or copy from code snippet to start the FTL server
o This command starts the FTL server process and its configured services
 o You can minimize the terminal window, but do not close it
 Now, access FTL server using a browser window and view application loaded by default
o Open Firefox Browser
o Enter the FTL server URL
o Click SIGN IN with User Id anyone
o Verify Applications tab is displayed with the default application as shown

#3
Start a New Receiver Client Application
Play Video

 Minimize the Firefox browser

 Open a new terminal and rename its title as Receive Messages
 Enter the commands as shown to view the available options for receiver program
 Enter the command as shown or copy from code snippet to start the receiver program
o Observe the command throws an error stating Realm not responding
o The error indicates that the program is expecting an application named tibrecv to be defined
o So, re-run the program and override the application name
 Stop the program using <Ctrl+c> keyboard buttons
 Start the receiver program again using the existing configuration as shown
o Verify that the program starts up and is waiting for messages
 tibrecvex is an enhanced version of tibrecv that provides options to vary application name, message count and so
on

#4
Send Messages and Verify the Messages are Received
Play Video

 Open a new tab in the Receive Messages terminal and name it as Send Messages
 Examine the options for the message sender program as shown
  Run the sender program with the updated application and endpoint names as shown
 Go back to Receive Messages terminal and observe the client received the message
 Both the programs are terminated after one message
 Analysis: This shows that the application definition in the FTL server can be used by a properly configured
client program. The client program locates the definition of the application and sends and receives messages
using the transports and endpoints defined for that application. Application definition (metadata) and clients are
truly decoupled.
 Open a new terminal and enter the commands as shown or copy from the code snippet to stop the FTL server
 Close all the terminals and Firefox browser window
 Open a new terminal and enter the command as shown or copy from the code snippet to take backup of the
configuration file
o Close the terminal window
 This completes the exercise

Code Snippets
#create data folder
cd /opt/tibco/ftl/6.4/samples/yaml/eftl
sudo mkdir data
password: TIBCO7222

#open and edit the configuration file

sudo gedit tibftlserver_eftl.yaml
password: TIBCO7222

#Start the FTL server

cd /opt/tibco/ftl/6.4/bin
sudo ./tibftlserver -c
/opt/tibco/ftl/6.4/samples/yaml/eftl/tibftlserver_eftl.yaml -n ftlserver1
ftlserver1@localhost:8585
password: TIBCO7222

#view the available options for receiver program

cd /opt/tibco/ftl/6.4/samples/bin/advanced
./tibrecvex -h

#start the receiver program

./tibrecvex http://localhost:8585

#Start the receiver program using the existing configuration

./tibrecvex -a default -e default http://localhost:8585

#view the available options for sender program

./tibsendex -h
#Run the sender program with the updated application/endpoint names
./tibsendex -a default -e default http://localhost:8585

#Stop FTL server

cd /opt/tibco/ftl/6.4/bin
./tibftladmin -x --ftlserver http://localhost:8585

#Backup config files

sudo cp /opt/tibco/ftl/6.4/samples/yaml/eftl/*.yaml
/home/tibco/Lab_Files/Export/LabH
password: TIBCO7222

Start a New Receiver Client Application

Play Video

 Minimize the Firefox browser

 Open a new terminal and rename its title as Receive Messages
 Enter the commands as shown to view the available options for receiver program
 Enter the command as shown or copy from code snippet to start the receiver program
o Observe the command throws an error stating Realm not responding
o The error indicates that the program is expecting an application named tibrecv to be defined
o So, re-run the program and override the application name
 Stop the program using <Ctrl+c> keyboard buttons
 Start the receiver program again using the existing configuration as shown
o Verify that the program starts up and is waiting for messages
 tibrecvex is an enhanced version of tibrecv that provides options to vary application name, message count and so
on

#4
Send Messages and Verify the Messages are Received
Play Video

 Open a new tab in the Receive Messages terminal and name it as Send Messages
 Examine the options for the message sender program as shown
 Run the sender program with the updated application and endpoint names as shown
 Go back to Receive Messages terminal and observe the client received the message
 Both the programs are terminated after one message
 Analysis: This shows that the application definition in the FTL server can be used by a properly configured
client program. The client program locates the definition of the application and sends and receives messages
using the transports and endpoints defined for that application. Application definition (metadata) and clients are
truly decoupled.
 Open a new terminal and enter the commands as shown or copy from the code snippet to stop the FTL server
 Close all the terminals and Firefox browser window
 Open a new terminal and enter the command as shown or copy from the code snippet to take backup of the
configuration file
o Close the terminal window
 This completes the exercise

Code Snippets
#create data folder
cd /opt/tibco/ftl/6.4/samples/yaml/eftl
sudo mkdir data
password: TIBCO7222

#open and edit the configuration file

sudo gedit tibftlserver_eftl.yaml
password: TIBCO7222

#Start the FTL server

cd /opt/tibco/ftl/6.4/bin
sudo ./tibftlserver -c
/opt/tibco/ftl/6.4/samples/yaml/eftl/tibftlserver_eftl.yaml -n ftlserver1
ftlserver1@localhost:8585
password: TIBCO7222

#view the available options for receiver program

cd /opt/tibco/ftl/6.4/samples/bin/advanced
./tibrecvex -h

#start the receiver program

./tibrecvex http://localhost:8585

#Start the receiver program using the existing configuration

./tibrecvex -a default -e default http://localhost:8585

#view the available options for sender program

./tibsendex -h

#Run the sender program with the updated application/endpoint names

./tibsendex -a default -e default http://localhost:8585

#Stop FTL server

cd /opt/tibco/ftl/6.4/bin
./tibftladmin -x --ftlserver http://localhost:8585

#Backup config files

sudo cp /opt/tibco/ftl/6.4/samples/yaml/eftl/*.yaml
/home/tibco/Lab_Files/Export/LabH
password: TIBCO7222

Unit 9: Lecture
Applications and Transports

Update a Realm
 To make any configuration changes the administrator needs to lock the realm to edit. The default mode is
unlocked, so a novice user can browse through the settings without any impact on the configuration.
 Once the realm is locked changes can be made. A realm is locked and a workspace is created. Administrators
make changes in this workspace and then decide if they want to deploy changes or discard them.
  Changes are not activated until the administrator deploys the changes. The administrator can save, discard, revert
or deploy the changes that have been made.
 The deployment history shows all the deployments that have been made to the realm. You can roll back to a
point of time of last or earlier deployments if needed, and that is why it is important to do each deployment with
the right name and description.

Applications and Endpoints

 An Application is a logical construct which defines the details for a publishing or a subscribing client.
 Programs send messages using publisher objects and receive messages using subscriber objects.
 Applications obtain operational metadata from a realm service. The realm service funnels operational metrics
from application clients to external monitoring points.
 An application has endpoints, transports and message formats. Transports define the physical data distribution
model for a given endpoint.
 Endpoint is a logical reference used by an FTL client to send or receive data. It denotes a place within an FTL
program where messages can enter and exit the program. Endpoints map to physical data distribution paths called
transports. An Application can have one to many endpoints used by the application process to send/receive data.
 Endpoints can have mappings for a single transport or multiple transports.
 From the application’s perspective, messages flow between endpoints. Messages exit the sending application
program at its endpoint, and enter the receiving application program at its endpoint.
 You can define applications and their endpoints in the applications grid of the FTL server GUI.
 Programs use endpoint names only to create publishers and subscribers.
 Programs can create several publishers and subscribers on a single endpoint.

Transports
Transports represent a physical connection configuration for communication. Messages travel from publishers to
subscribers over transports. The publishers and subscribers on a transport all use the transport in common as a shared
communication medium. The supported transport types are:

 Dynamic TCP Transport: Decouples transport definitions from hosts and ports.
 Static TCP Transport: Communicates over a set of dedicated connections.
 Multicast Transport (mcast): Carries a reliable multicast communication among endpoints on many host
computers. Multicast transports are efficient for high fan-out communication across a LAN. It uses a negative
acknowledgement protocol for reliable message transfer.
 Process Transport (PROC): For endpoints within a single program process. Process transports communicate at
high speeds and exhibit very low latency.
 Shared Memory Transport: Endpoints in programs that run on the same host computer. Shared memory
transports communicate at high speeds and exhibit very low latency.
 Direct Shared Memory Transport: Like shared memory transports, with some additional restrictions. They
communicate at high speeds and exhibit extremely low latency.
 Reliable UDP Transport (RUDP): Carries reliable communication over a set of dedicated connections.
Endpoints on an RUDP bus exchange UDP datagrams. Uses a positive acknowledgment protocol.
 Remote Direct Memory Access Transport (RDMA): Network adapters can move data directly from memory
in one computer to memory in another computer across a network.

TCP Transport Details

 Static TCP is the classic option, where ports are configured and setup by the FTL server administrator. It is a
connection oriented protocol. It supports connect and listen mode. Connect endpoints connect to all listening
endpoints within a transport group to establish a bus. Listen endpoints establish a bus by listening for
connections within a transport group. At least three parameters, host, port and mode needs to be specified for
 Static TCP transport. For host, specify an interface either as a host name or an IP address. Asterisk is a special
value, which designates all interfaces on the host computer.
 Dynamic TCP transport allocates ports based on availability. It supports three types of mode: mesh, connect and
listen. This is the recommended option when using TCP, as it provides more flexibility. The downside is opening
specific firewall ports becomes challenging. You can overcome this by assigning a port range for this purpose.
 Both the transports support SSL based security.

Unitary vs. Fragmentary Transports

Transports can be divided into two types, based on their communication patterns.

Unitary: Transports use the same transport definition to establish a bus. Definitions of dynamic
TCP mesh transports, shared memory transports, and process transports are inherently unitary.

Fragmentary: Transports use at least two different transport definitions, which cooperate to
establish a bus. Definitions of static TCP, dynamic TCP listen/connect pairs, RDMA, and
Reliable UDP transports are inherently fragmentary. Dynamic TCP transport supports both
patterns:

 Unitary: Mesh Endpoints form a full mesh.

 Fragmentary: Listen Endpoints establish a bus by listening for connections within a
transport group. Connect Endpoints establish a bus by connecting to all listening
endpoints within a transport group.

Define Transports
 Use FTL server GUI to define transport. The name, description and transport type parameters of a transport are
mandatory fields.
 The details for a transport being configured depends on the transport type selected. For example, if you select
TCP, you see the hostname and TCP port settings window.
 You can also specify the abilities that the transport carries for the endpoint. Available abilities are Receive, Send,
Receive Inbox, and Send Inbox. At least one ability for each transport must be enabled

Define Applications and Endpoints

 Applications and endpoints are also defined from the FTL server user interface.
 Basically, an application definition consists of a name, a set of endpoints, a set of application instance
definitions, and a set of preload format.
 These are defined from the Applications tab in the UI.
 Realm should be locked in edit mode to allow defining applications.
 Use plus sign to add a new application and enter the application name. The three dots above the application name
is used to define new instances of the same application, if needed.
 You can define one or more endpoints for an application. When running an application, an FTL client can select
a specific endpoint, or choose to use the default endpoint.
 The default endpoint may be an endpoint named default. If default is not present, it will pick up the first one in
the list of endpoints. An endpoint in turn may be associated with one or more transports.
 An endpoint decides the abilities of the transport:
o One to Many (receive): Subscriber
o One to One: Inbox Subscriber
 o One to Many send: Publisher
o One to one send: Send to Inbox

Use Application Instances

 Application instance definitions configure the implementation of endpoints for process instances of an
application. This is a convenience parameter in case a single application has to use multiple endpoints.
 Simply define an instance name and associate it with a specific endpoint.
 When named correctly, you can choose to run a specific instance and the endpoint and transport definition is
picked up automatically.
 An application instance definition consists of a name, a set of match parameters, and a set of connectors to
implement each endpoint.
 When Application Instances are used, there is no need to configure a transport connector for an endpoint.
 You configure a series of Application Instances which then map to one or multiple transport connectors.
 Application Instances are named objects and the default instance is used if the application doesn’t specify a
configured instance.
 Application instances provides flexibility to application design and administration.

Use Application Instances

 Application instance definitions configure the implementation of endpoints for process instances of an
application. This is a convenience parameter in case a single application has to use multiple endpoints.
 Simply define an instance name and associate it with a specific endpoint.
 When named correctly, you can choose to run a specific instance and the endpoint and transport definition is
picked up automatically.
 An application instance definition consists of a name, a set of match parameters, and a set of connectors to
implement each endpoint.
 When Application Instances are used, there is no need to configure a transport connector for an endpoint.
 You configure a series of Application Instances which then map to one or multiple transport connectors.
 Application Instances are named objects and the default instance is used if the application doesn’t specify a
configured instance.
 Application instances provides flexibility to application design and administration.

Understand tiblatsend and tiblatrecv

The tiblatsend and tiblatrecv are used to test latency for a specific transport configuration. Common arguments are:

 -a: load an application definition from the realm

 -e: send messages on the endpoint

You can define your own applications, endpoints and transports to be used with tiblatsend and tiblatrecv.

Furthermore, you can vary the message count and get results for a smaller test set.
Request/Reply Messaging
 The tiblatsend sends a ping message and the tiblatrecv replies back with a pong message. These messages are
not visible to the user, as the focus is on sending plenty of messages (5 million is the default setting) to test
latency.
 Latency is the time between the request and response.
  The tiblatsend program sends 5 million messages and calculates the total latency for all messages, and displays
the numbers at the end of the run. The tiblatrecv program does not display messages. If the tiblatsend program
does not end, it indicates that it did not connect to the receiver and did not receive any pong replies.

Unit 9: Lab
Lab I Exercise 1
Implement Reliable UDP Transport
Play Video

In this exercise, define a Reliable UDP transport and create an application for it from TIBCO FTL server UI.

Later deploy the configuration and test the performance of RUDP transport.
START

#1
Start the FTL Server and Access using a Browser
Play Video

 Open a new terminal and enter the command as shown or copy it from the code snippet to restore the original
configuration files
 Close the terminal window
 Next, start the FTL server
o Open a new terminal and name it as FTL Server
o Enter the commands as shown or copy from the code snippet to start the server
 Now, access FTL server using a browser window
o Minimize the terminal window
o Open Firefox Browser
o Enter the FTL server URL (http://localhost:8585)
o Click SIGN IN with User Id anyone

#2
Define RUDP Transports
Play Video

 From the FTL server UI, set Edit Mode to On

 Select Transports tab, click + sign to add a new transport
o Enter the details as shown:
o Transport (name): rudpconnect
o Transport Type: Reliable UDP
o Address: localhost
o Port: 8860
o Mode: connect
 Add another transport for reliable UDP using listen mode
o Add a new transport and enter the following details as shown
o Transport (name): rudplisten
o Transport Type: Reliable UDP
o Address: localhost
o Port: 8860
o Mode: listen
 Note that both the transports use localhost and port 8860
  RUDP is a connection-oriented protocol
 Its transport definitions are inherently fragmentary
 At least two complementary transport definitions are required to establish a bus

#3
Define an Application and Deploy the Changes
Play Video

 From FTL server UI, select Applications tab and click + to add a new application
 Enter the details for the following parameters as shown:
o Name: udp-app
o Endpoint: listen-ep
o Transport: rudplisten
 Add another endpoint to the udp-app application
o Click ellipsis (...) sign above the udp-app name and select Add Endpoint option
o Enter the following parameter details as shown
o Endpoint: connect-ep
o Cluster: ftl.default.cluster
o Store: ftl.nonpersistent.store
o Durable Template: ftl.pubsub.template
o Transport: rudpconnect
 Now, validate and deploy the changes
o Click Validation Results tab under Validation menu and verify that there are no errors
o Click Deploy option at the top right of the window
o In the Deploy dialog, enter the Name
o Click Test and then click Deploy
o The deployment summary screen is displayed
o Verify that the deployment is successful and then click Done
 After the deployment, if the FTL server stays in edit mode, turn edit mode to off and discard changes before
continuing

#4
Send and Receive Messages
Play Video

 Start message receiver program using the udp-app definition

o Minimize the Firefox browser
o Open a new terminal window and name its title as Receive Messages
o Enter the commands as shown or copy from the code snippet to see available options for the receiver
program
o Enter the command as shown to start the receiver program
o Both sending and receiving transport are the same
o The program starts up with few warnings that can be ignored
 Start the send program and confirm request-reply works as expected
o Open a new tab from Receive Messages terminal and name its title as Send Messages
o Enter the command as shown or copy from the code snippet to start the sender program
o Again, same transport is used for both transmit and receive endpoints
o The program sends 1000 messages and quits as shown
 Observe that RUDP works as expected
 Note that tiblatrecv program displays the total time taken to send 1000 messages
 This completes the exercise
Code Snippets
#Copy original configuration files
sudo cp /home/tibco/Lab_Files/Original/FTL/tibftlserver_eftl.yaml
/opt/tibco/ftl/6.4/samples/yaml/eftl
password: TIBCO7222

#Start FTL server

cd /home/tibco/Scripts
./start-ftl-server.sh
password: TIBCO7222

#Receiver help command

cd /opt/tibco/ftl/6.4/samples/bin/advanced
./tiblatrecv -h

#Start receiver program

./tiblatrecv -a udp-app -et listen-ep -er listen-ep http://localhost:8585

#Start sender program

./tiblatsend -a udp-app -et connect-ep -er connect-ep -c 1000
http://localhost:8585
Lab I Exercise 2
Illustrate Multicast Transport Configuration
Play Video

In this exercise, define a multicast transport and an application for it from TIBCO FTL server UI.

Deploy the configuration and test the performance of multicast transport.

START

#1
Define a New Multicast Transport
Play Video

 From the FTL server UI, set Edit Mode to On

 Click Transports tab, add a new transport and enter the following details as shown
o Transport (name): mcast
o Transport Type: Multicast
o Address: 239.1.1.10
o Port: 8850
o Mode: send group
 Click ellipsis (...) above mcast transport name and select View Detailsoption
o In Interface and Address Settings, enter Host as localhost
o Under Listen Groups, click + New Listen Group
o Enter the IP provided for mcast transport
o Click Save
 Final configuration should appear as shown
 This multicast uses the same send and listen group in the unitary use case
 If configuring for fragmentary case, you can define different send and listen groups as well
 The IP address used is a Class D address, required for multicasting

#2
Define a New Application that uses the Multicast
Transport
Play Video

 Click + to add a new application

 Enter the following details as shown
o Name: mcast-app
o Endpoint: common-ep
o Transport: mcast
o Other details are auto filled
 Next, validate and deploy the changes
o Click Validation Results tab under Validation menu and verify that there are no errors
o Click Deploy option at the top right of the window
o In the Deploy dialog, enter the Name
o Click Test and then click Deploy
o The deployment summary screen is displayed
o Verify that the deployment is successful and then click Done

#3
Send and Receive Messages using the mcast-app
Definition
Play Video

 Go to the terminal named Receive Messages and run the command as shown to start the receiver program
 Go to the terminal window named Send Messages and enter the command as shown or copy from the code
snippet to start the sender program
o The program sends 1000 messages and quits as shown
 Observe the Total time required to send 1000 messages using multicast transport
 Open a new terminal and enter the commands as shown or copy from the code snippet to stop the FTL server
 Close all the terminals and Firefox browser window
 Lastly, open a new terminal and enter the command as shown to take backup of the configuration file
 Close the terminal window
 This completes the exercise

Code Snippets
#Start receiver program
./tiblatrecv -a mcast-app -et common-ep -er common-ep http://localhost:8585

#Start sender program

./tiblatsend -a mcast-app -et common-ep -er common-ep -c 1000
http://localhost:8585
Unit 10: Lecture

Introduce Transport Bridge

 A transport bridge is a process that efficiently forwards messages among sets of transport buses.
 It is used to connect same or different types of FTL client transports.
 Typically, a transport bridge is needed when messages sent by FTL clients on one transport need to be consumed
by FTL clients using a different transport.
 Transport bridges are implemented by bridge services defined in the FTL server configuration file.
 It reduces the amount of duplicate configuration and allows for seamless bi-directional messaging between the
two types of clients.
 Two transports can be bridged by administrator user only.

Features
Following are the features of transport bridge:

 A transport bridge operates within a single realm. It means that messages cannot be forwarded between two
realms using a transport bridge.
 A transport bridge provides a low latency alternative to forwarding messages as compared to another FTL client.
 Transports can be of the same type, or they can be of different transport protocols. For example, you can bridge
between shared memory and RDMA transports.
 A transport bridge only supports bi-directional non-blocking transports. For example, a bridge cannot support a
multicast transport configured with a send group but without a listen group, nor vice versa.
 You can define multiple transport bridges, but make sure that the bridges do not end up creating a loop as
transport bridge does not support loop configuration. Transport bridges can forward one-to-many messages and
one-to-one messages. Transport bridges support one-to-one messages on transports that support inbox abilities.

Topologies
Transport bridge supports three topologies.

 One Bridge: The most common topology is to bridge two transports using a bridge. These transports can be on
the same host or different hosts.
 Serial Bridge: Serial bridge topology is useful for bridging shared memory transports on different hosts. Shared
Memory messages are restricted to the same host. This requires two bridges, the first bridge is between Shared
Memory and RDMA transports on the first host. The second bridge is between RDMA and Shared Memory
transports on the second host to consume the messages. Since RDMA goes across hosts, this is a logical solution.
 The third topology is explained in the next slide.

Topologies
 Hub-and-Spoke bridge topology is useful to connect partner enterprises, specially at remote sites.
 In this topology, you can use multiple transport bridges as shown above.
 On the “hub” side, a single transport (in one set) forwards messages to multiple transports (in another set).
 Each “spoke” has a transport bridge to have one-to-one forwarding from one transport. So all Static TCP
messages may be forwarded to TCP, all Dynamic TCP messages may be forwarded to UDP and so on.
  Messages can be further restricted by using content matchers. The partner enterprises (spokes) share data with
main enterprise (hub), but the partner enterprise must not share data with each other.
 To extend this topology, you can add transport sets, or add transports to the transport sets.
 You may also extend this topology by adding more spokes, each consisting of a spoke bus, a spoke bridge, and a
local bus.
 You cannot extend this topology by adding a third serial bridge, neither to the main enterprise hub bus, nor to
any local spoke bus.
 Also, this topology cannot be extended by adding a second branching spoke bridge to any transport in the
transport set.

Transport Bridge Configuration

 A transport bridge is specified in the Bridges section of the FTL server UI. Following are the parameters related
to transport bridge configuration:
o Bridge: Under this parameter, enter the name of the bridge. This name must be globally unique within
the realm.
o Transport Set: A bridge definition consists of two or more transport sets. So, at least two transport sets
must be defined in each bridge. Transports set names are generated automatically and cannot be
changed by the user.
o Transport: Each transport set can contain one or more transports. This allows to define a set of
transports that forward messages to a different set of transports. Message forwarding happens between
transport sets. So messages from any one transport in a set will be forwarded to all transports in the
other sets. They will not be forwarded to the transport within the originating set.
o Protocol: It displays details of the transport definition.

Bridge Service
 Transport bridge services are defined in the FTL server configuration file.
 Bridge services implement the transport bridges that are defined in the realm definition. Any FTL server can
provide and manage a bridge service.
 Each bridge service can implement one or more bridge objects as defined in the realm definition. These bridge
objects are independent. Even though one bridge service could implement several bridge objects, messages do
not cross from one bridge to another bridge.
 When the bridge definitions or the transport definitions are modified or updated, the FTL server automatically
restarts the affected bridge services that implement those bridge objects.

Fault Tolerant Transport Bridge

 You can run two or more bridge services for fault-tolerant operation. Although this feature ensures automatic and
quick recovery, failover might leave some messages unforwarded.
 To establish fault-tolerant bridge services, two or more bridge services must be configured in separate FTL
servers.
 Fault-tolerant bridges rely on the group service to coordinate fault tolerance. The Group service is a part of FTL
server, that cannot be configured, disabled, or purged.
 FTL server automatically starts Group service along each realm service. Group service automatically ensures that
only one of the fault-tolerant bridge services is active at a time, while the other service remains in standby mode.

Examine Transport Bridge Function

Play Video
In this exercise, configure FTL server to enable bridge service.
START
#1
Update FTL Server YAML Configuration File to Include
Bridge Service
Play Video

 Open a new terminal window and name its title as FTL Server
 Enter the command as shown or copy from code snippet to create a new folder named data
 From the same terminal, enter the command as shown or copy from the code snippet to open and edit the
configuration file
o Edit the configuration file as shown
o Delete or comment the configurations for ftlserver2 and ftlserver3 from globals and servers section
o Enter the path for data parameter
o The FTL server stores its working data files in this path location
o Change the bridge name brdg to SHM-DTCP from servers section
 Save and close the file

#2
Start the FTL Server and Access it using a Browser
Window
Play Video

 From the same terminal, enter the commands as shown or copy from the code snippet to start the FTL server
o Observe that FTL server starts but with a warning _Bridge_SHM-DTCP does not exist
 Note: The warning indicates that the bridge name defined in the configuration file does not exist in the realm
data. Once the bridge with defined name is created in the FTL server UI, this warning is removed.
 Now, access FTL server using a browser window
o Open Firefox Browser
o Enter the FTL server URL
o Click SIGN IN with User Id anyone
 From the FTL server UI, set Edit Mode to On
 Click Actions option at the top right corner and select Upload config
o Browse to /home /Lab_Files /Export /LabJ
o Select RealmForBridges.json and click Open
 Check the updated realm and confirm the following:
o From Applications tab,
o There are 3 applications
o myshmapp uses shared memory transport (myshm-tport)
o mydtcpapp uses Dynamic TCP Transport (myDTCP)
o From Transports tab,
o There are three defined transports
 Click Services option at top of the window and observe that Bridge service is not yet running
 1

#3
Add a New Bridge to Connect Shared Memory and
Dynamic TCP Transports
Play Video

 Select Bridges tab and click + to add a new Bridge definition

 Enter the following parameters details as shown:
o Bridge: SHM-DTCP
o Transport Set 0: myshm-tport
o Transport Set 1: myDTCP
 Validate and Deploy the changes
o Enter Deployment Name
 Click Services option and verify that the bridge service is running
o If the Bridge service is still not running, refresh the browser and check again

#4
Test the Working of Transport Bridge
Play Video

 Start the message subscriber program using the shared memory transport application
o Minimize the Firefox browser
o Open a new terminal and name it as Receive Messages
o Type the commands as shown or copy from the code snippet to start the receiver program
 Next, open a new terminal tab and name it as Send Messages
 Type the commands as shown or copy from the code snippet to start the sender program and send 10 messages
 Go back to Receive Messages terminal and verify the receiver receives 10 messages and terminates
 This confirms the working of the transport bridge
 Open a new terminal and enter the commands as shown or copy from the code snippet to stop the FTL server
 Close all the terminals and Firefox browser window
 Lastly, open a new terminal and enter the command as shown to take backup of the configuration file
  Close the terminal window
 This completes the exercise

Code Snippets
#Create a folder
cd /opt/tibco/ftl/6.4/samples/yaml/bridge
sudo mkdir data
password: TIBCO7222

#Open and edit config file

sudo gedit tibftlserver_bridge.yaml
password: TIBCO7222

#Start FTL server

cd /opt/tibco/ftl/6.4/bin
sudo ./tibftlserver -c
/opt/tibco/ftl/6.4/samples/yaml/bridge/tibftlserver_bridge.yaml -n ftlserver1
ftlserver1@localhost:8585
password: TIBCO7222

#Start message subscriber program

cd /opt/tibco/ftl/6.4/samples/bin/advanced
./tibrecvex -a myshmapp -e myshm-ep -c 10 localhost:8585

#Start message sender program

cd /opt/tibco/ftl/6.4/samples/bin/advanced
./tibsendex -a mydtcpapp -e mydtcp-ep -c 10 -d 1000 localhost:8585

#Stop FTL server

cd /home/tibco/Scripts
./stop-ftl-server.sh

#Backup config file

sudo cp /opt/tibco/ftl/6.4/samples/yaml/bridge/*.yaml
/home/tibco/Lab_Files/Export/LabJ
password: TIBCO7222

Update FTL Server YAML Configuration File to Include

Bridge Service
Play Video
  Open a new terminal window and name its title as FTL Server
 Enter the command as shown or copy from code snippet to create a new folder named data
 From the same terminal, enter the command as shown or copy from the code snippet to open and edit the
configuration file
o Edit the configuration file as shown
o Delete or comment the configurations for ftlserver2 and ftlserver3 from globals and servers section
o Enter the path for data parameter
o The FTL server stores its working data files in this path location
o Change the bridge name brdg to SHM-DTCP from servers section
 Save and close the file# 2

Start the FTL Server and Access it using a Browser

Window
Play Video

 From the same terminal, enter the commands as shown or copy from the code snippet to start the FTL server
o Observe that FTL server starts but with a warning _Bridge_SHM-DTCP does not exist
 Note: The warning indicates that the bridge name defined in the configuration file does not exist in the realm
data. Once the bridge with defined name is created in the FTL server UI, this warning is removed.
 Now, access FTL server using a browser window
o Open Firefox Browser
o Enter the FTL server URL
o Click SIGN IN with User Id anyone
 From the FTL server UI, set Edit Mode to On
 Click Actions option at the top right corner and select Upload config
o Browse to /home /Lab_Files /Export /LabJ
o Select RealmForBridges.json and click Open
 Check the updated realm and confirm the following:
o From Applications tab,
o There are 3 applications
o myshmapp uses shared memory transport (myshm-tport)
o mydtcpapp uses Dynamic TCP Transport (myDTCP)
o From Transports tab,
o There are three defined transports
 Click Services option at top of the window and observe that Bridge service is not yet running

#3
Add a New Bridge to Connect Shared Memory and
Dynamic TCP Transports
Play Video
  Select Bridges tab and click + to add a new Bridge definition
 Enter the following parameters details as shown:
o Bridge: SHM-DTCP
o Transport Set 0: myshm-tport
o Transport Set 1: myDTCP
 Validate and Deploy the changes
o Enter Deployment Name
 Click Services option and verify that the bridge service is running
o If the Bridge service is still not running, refresh the browser and check again

#4
Test the Working of Transport Bridge
Play Video

 Start the message subscriber program using the shared memory transport application
o Minimize the Firefox browser
o Open a new terminal and name it as Receive Messages
o Type the commands as shown or copy from the code snippet to start the receiver program
 Next, open a new terminal tab and name it as Send Messages
 Type the commands as shown or copy from the code snippet to start the sender program and send 10 messages
 Go back to Receive Messages terminal and verify the receiver receives 10 messages and terminates
 This confirms the working of the transport bridge
 Open a new terminal and enter the commands as shown or copy from the code snippet to stop the FTL server
 Close all the terminals and Firefox browser window
 Lastly, open a new terminal and enter the command as shown to take backup of the configuration file
 Close the terminal window
 This completes the exercise

Code Snippets
#Create a folder
cd /opt/tibco/ftl/6.4/samples/yaml/bridge
sudo mkdir data
password: TIBCO7222

#Open and edit config file

sudo gedit tibftlserver_bridge.yaml
password: TIBCO7222

#Start FTL server

cd /opt/tibco/ftl/6.4/bin
sudo ./tibftlserver -c
/opt/tibco/ftl/6.4/samples/yaml/bridge/tibftlserver_bridge.yaml -n ftlserver1
ftlserver1@localhost:8585
password: TIBCO7222

#Start message subscriber program

cd /opt/tibco/ftl/6.4/samples/bin/advanced
./tibrecvex -a myshmapp -e myshm-ep -c 10 localhost:8585

#Start message sender program

cd /opt/tibco/ftl/6.4/samples/bin/advanced
./tibsendex -a mydtcpapp -e mydtcp-ep -c 10 -d 1000 localhost:8585

#Stop FTL server

cd /home/tibco/Scripts
./stop-ftl-server.sh

#Backup config file

sudo cp /opt/tibco/ftl/6.4/samples/yaml/bridge/*.yaml
/home/tibco/Lab_Files/Export/LabJ
password: TIBCO7222