Ems Best Practices

http://www.tibco.
com
Global Headquarters
3303 Hillview Avenue
Palo Alto, CA 94304
Tel: +1 650-846-1000
Toll Free: 1 800-420-8450
Fax: +1 650-846-1005
Copyright 2004, TIBCO Software Inc. All
rights reserved. TIBCO, the TIBCO logo, The
Power of Now, and TIBCO Software are
trademarks or registered trademarks of
TIBCO Software Inc. in the United States
and/or other countries. All other product and
company names and marks mentioned in
this document are the property of their
respective owners and are mentioned for
identification purposes only. 0204
TIBCO Enterprise Messaging
Service (EMS) Best Practices
This is a TIBCO Best Practices document from TIBCO Professional Services
Group.
This document provides best practices for developing and deploying applications
using TIBCO EMS (formerly known as TIBCO Enterprise for JMS). This is not a
JMS introductory or overview document, nor is it a JMS API development guide.
It assumes that readers have basic knowledge of JMS and familiarity of TIBCOs
EMS product.
Integration architects and developers can use this document to establish
company-specific development and deployment guidelines, or simply can use it
as a reference.
Unless otherwise noted in the document, its content is compatible and updated
with EMS release 4.x or later.
TIBCO EMS Best Practices
2
Table of Contents
1 INTRODUCTION.........................................................................................................................................................4
1.1 EMS DEVELOPMENT BACKGROUND.....................................................................................................................4
1.2 TO THE APPLICATION DEVELOPERS......................................................................................................................5
1.3 TO THE INFRASTRUCTURE TEAM...........................................................................................................................6
1.4 TO THE BEST PRACTICES GURU ............................................................................................................................7
1.5 HOW TO USE THIS DOCUMENT..............................................................................................................................7
1.6 OTHER SOURCES OF EMS BEST PRACTICES.........................................................................................................7
2 EMS CLIENT BEST PRACTICES............................................................................................................................8
2.1 MESSAGING NAMING STANDARD..........................................................................................................................8
2.2 JMS MESSAGES .....................................................................................................................................................8
2.2.1 Use of Message Header Fields ........................................................................................................................9
2.2.1.1 JMSDestination Header Field.................................................................................................................................. 9
2.2.1.2 JMSDeliveryMode Header Field........................................................................................................................... 10
2.2.1.3 JMSExpiration Header Field ................................................................................................................................. 11
2.2.1.4 JMSPriority Header Field ...................................................................................................................................... 11
2.2.1.5 JMSMessageID Header Field................................................................................................................................ 11
2.2.1.6 JMSTimeStamp Header Field................................................................................................................................ 12
2.2.1.7 JMSReplyTo Header Field .................................................................................................................................... 12
2.2.1.8 JMSCorrelationID Header Field............................................................................................................................ 12
2.2.1.9 JMSMessageType Header Field............................................................................................................................ 12
2.2.1.10 JMSRedelivered Header Field............................................................................................................................... 13
2.2.2 Use of Message Properties Fields .................................................................................................................13
2.2.2.1 Provider-Specific Properties.................................................................................................................................. 13
2.2.2.2 Optional JMS-Defined Properties ......................................................................................................................... 15
2.2.2.3 Application Properties............................................................................................................................................ 15
2.2.2.4 Message Selectors .................................................................................................................................................. 16
2.2.3 Message Payload Types .................................................................................................................................17
2.2.4 Message Wire Formats ..................................................................................................................................18
2.2.5 Message Compression....................................................................................................................................19
2.2.6 Message Encryption.......................................................................................................................................19
2.3 QUEUES VS. TOPICS .............................................................................................................................................21
2.3.1 EMS Queue Infrastructure.............................................................................................................................22
2.3.1.1 Queue Message Flow Control ............................................................................................................................... 22
2.3.1.2 Scaling and Performance Tuning of JMS Queues with EMS.............................................................................. 23
2.3.2 EMS Topic Infrastructure ..............................................................................................................................26
2.3.2.1 Topic Message Routing ......................................................................................................................................... 26
2.3.2.2 Topic Flow Control ................................................................................................................................................ 27
2.3.2.3 Durable Topics ....................................................................................................................................................... 28
2.3.2.4 Scaling and Performance Tuning of JMS Topics with EMS ............................................................................... 29
2.4 TEMPORARY, DYNAMIC AND STATIC DESTINATIONS.........................................................................................30
2.5 QUEUE BROWSER USAGE ....................................................................................................................................31
2.6 SECURE CLIENT CONNECTIONS...........................................................................................................................32
2.6.1 Infrastructure Authentication.........................................................................................................................32
2.6.2 Administrator Authentication and Authorization..........................................................................................33
2.6.3 Application Authorization..............................................................................................................................34
2.6.4 EMS Routing Authentication and Authorization...........................................................................................34
2.6.5 Use of SSL and Authentication within EMS..................................................................................................34
2.7 JNDI LOOKUP......................................................................................................................................................36
2.8 WORKING WITH TRANSACTIONS .........................................................................................................................37
2.9 SYNCHRONOUS AND ASYNCHRONOUS INTERACTION.........................................................................................38
2.10 CLIENT FAULT TOLERANCE.................................................................................................................................40
3
2.10.1 Client Fault Tolerance and Delay in Failover.........................................................................................40
2.10.2 Client Fault-Tolerant State Transition Trapping.....................................................................................42
2.10.3 Tibjms Object.............................................................................................................................................43
2.11 PRE-PACKAGED TIBCO EMS APPLICATIONS ....................................................................................................44
2.11.1 Using EMS in BW......................................................................................................................................44
2.11.2 Using EMS in Adapters.............................................................................................................................44
2.11.3 Using Rendezvous over EMS and Rendezvous/EMS Bridging................................................................45
2.11.4 Using Hawk over EMS..............................................................................................................................45
2.12 INTEGRATION WITH EJB APP SERVERS...............................................................................................................46
3 EMS SERVER BEST PRACTICES.........................................................................................................................47
3.1 SYSTEM REQUIREMENT AND PLANNING.............................................................................................................47
3.1.1 Network Architecture .....................................................................................................................................47
3.1.2 Storage Architecture ......................................................................................................................................48
3.1.2.1 Storage Hardware................................................................................................................................................... 48
3.1.2.2 File Systems............................................................................................................................................................ 48
3.1.3 Physical Server Architecture .........................................................................................................................48
3.1.3.1 CPU and Memory................................................................................................................................................... 48
3.1.3.2 I/O Subsystems....................................................................................................................................................... 50
3.2 BASIC EMS DAEMON (SERVER) ELEMENT.........................................................................................................50
3.3 DESIGN FOR FAULT TOLERANCE.........................................................................................................................52
3.3.1 Fault-Tolerant Server Element ......................................................................................................................53
3.3.2 Clustering .......................................................................................................................................................54
3.3.2.1 Clustering and a Service Bus Deployment............................................................................................................ 56
3.3.2.2 Clustering and an Enterprise Backbone (EB) ....................................................................................................... 57
3.3.3 Architectural Difference Between Project Stages.........................................................................................58
3.3.4 Shared Storage System...................................................................................................................................59
3.3.5 Disaster Recovery Design..............................................................................................................................59
3.4 DESIGN FOR OPTIMAL PERFORMANCE................................................................................................................59
3.4.1 Server Routing................................................................................................................................................61
3.4.2 Destination Bridging......................................................................................................................................61
3.5 CLIENT MANAGEMENT........................................................................................................................................62
3.5.1 Client Registration and Name Proliferation .................................................................................................62
3.5.2 Client Authentication......................................................................................................................................62
3.5.3 Client Authorization.......................................................................................................................................62
3.5.4 SSL Connections.............................................................................................................................................62
3.6 SERVER MANAGEMENT .......................................................................................................................................62
3.6.1 Client Connection Management ....................................................................................................................62
3.6.2 Message Persistence ......................................................................................................................................63
3.6.3 Server Scaling.................................................................................................................................................63
3.6.4 Administration and Monitoring .....................................................................................................................64
3.6.4.1 EMS Command-Line Interface.............................................................................................................................. 64
3.6.4.2 Administration API ................................................................................................................................................ 65
3.6.4.3 Hawk Administration Software............................................................................................................................. 65
3.6.4.4 Integration with Other Administration Interfaces................................................................................................. 71
3.6.4.5 Tracing of the EMS Server .................................................................................................................................... 71
3.6.4.6 Message Tracing .................................................................................................................................................... 72
3.6.4.7 Monitoring Server Events through Topics............................................................................................................ 73
3.6.4.8 EMS Server Statistics............................................................................................................................................. 73
3.7 DEPLOYING EMS WITH OTHER TIBCO COMPONENTS......................................................................................74
3.7.1 Deploying EMS with BW 5.X.........................................................................................................................74
3.8 INTERACTING WITH OTHER JMS PROVIDERS .....................................................................................................76
3.9 MULTI-LANGUAGE INTEGRATION.......................................................................................................................77
4
1 Introduction
1.1 EMS Development Background
EMS is TIBCOs implementation of the JMS (Java Messaging Service) specification (v1.1), which is an API specification
from Sun and co-written by many other companies including TIBCO. As an industry-accepted messaging specification,
JMS is implemented and supported by many software vendors and is used widely for application integration.
EMS provides a more complete suite of messaging products and tools than simply the JMS API. It also provides a
critical infrastructure component that has implications on servers, storage, and network infrastructure. This document
will not cover JMS basics or API, which can be found at a variety of other sources. It assumes that readers have basic
knowledge of JMS and familiarity of TIBCOs EMS product.
EMS is a messaging infrastructure that supports the Java Messaging Service (JMS) Specification. JMS was designed
as an industry-standard interface to a Message-Oriented Middleware (MOM) infrastructure. MOM provides capabilities
for application messaging and integration that go far beyond the traditional client-server paradigms that have dominated
the computer industry for several decades. While JMS specifies the API, it is not an all-encompassing specification. It
is expected the MOM infrastructure would provide the following:
! Protocol Wire Format
! Metadata Repository
! Load Balancing and Fault-Tolerant Mechanisms
! Error Notification and Trace Information
! Administration API
! Security API
! Additional Language Bindings
Clearly, the infrastructure is a critical component in both the departmental and enterprise deployment of MOM-based
applications. It is, therefore, important to understand the features and capabilities available within the message
infrastructure to ensure that optimal application solutions are both designed and deployed. It is equally important that
the infrastructure provide an industrial-strength messaging foundation for the applications.
This document details the nuances and features of the EMS to ensure that architects and developers will be able to
exploit the capabilities to their fullest. Recommendations and architectures are provided to assist developers and
system architects in the design of highly optimized applications to fully meet the customers business requirements.
Best practices for the implementation and design of MOM-based applications within the EMS product base will also be
described.
There is no silver bullet to solve all application requirements with a single solution. Therefore, many of the suggestions
and comments in this document are provided as guidelines and recommendations and not necessarily rules for
installation and configuration. There are also trade-offs within a system design, and these require testing and
prototyping to determine the optimal solution. The pros and cons of different architectures and implementations
practices are highlighted throughout the document to assist system architects in making correct design decisions.
5
Many aspects and details of the JMS specification and TIBCOs implementation of the infrastructure to support the
specification will be detailed in this document. Unlike other documents, which are readily available as reference
documents, the discussion of the technology will be focused on relevancy to the EMS environment and on best
practices and recommendations for implementation of a complete messaging solution.
1.2 To the Application Developers
Application developers use EMS API or one of the packaged EMS client application (such as BW and TIBCO Adapters)
to develop applications. Developers are also not restricted to the use of Java and the JMS API to interact with strictly
other Java JMS applications. Through the EMS infrastructure, JMS and Java are only one of the alternatives for
interoperable messaging. Other programming languages are also available for application development that will
communicate through the EMS infrastructure with the JMS applications. In addition, EMS provides transparent bridging
between other messaging systems (such TIBCO Rendezvous and TIBCO Smart Sockets) and JMS without any special
API requirements.
All specialized features of EMS are provided without requiring specialized, non-standard, JMS API calls, to ensure JMS
API source code compatibility. The JMS API source code compatibility is the main objective of the specification. While
part of JMS is exposed for vendor-specific implementation (such as the connection factory), it is still possible to create
JMS-compliant applications that contain no TIBCO-specific code, even where it is allowed within the JMS specification.
It is important to note that there are two JMS API sets available. EMS supports both.
Most documents and books that describe JMS refer to the following programming model:
This is the original model of the JMS specification. Topics and queues were defined with specific interfaces. This
complicated the code base, and required specific knowledge of the mechanism used, either queue or topic.
6
Unfortunately, most of the literature on the market today that discusses JMS uses this model to describe and reference
sample JMS code. It is also, in many cases, used to describe best practices for writing JMS code. These older
reference materials should be discarded or ignored.
The current JMSv1.1 standard provides a less complex and more robust programming model:
It is recommended that the latest programming model be used for the creation of JMS applications. The older interfaces
are still available with the API library provided with EMS, but this is for purposes of supporting legacy JMS applications.
The old interfaces are not recommended for use, and may eventually be deprecated.
Included with the EMS distribution are several groups of sample code. The Java sample code includes examples of
programs that perform the same functions, but use the two different programming models to highlight the differences.
Included with the Java sample code are also example JMS programs from Sun, as well as several examples of Java
code that make use of the JNDI interface, which is recommended for use in obtaining connection factory and
destination information (except in the case of dynamic topics).
Also included with the EMS distribution are code samples for C and C#. Code samples that make use of the
Administration API are also included with the default EMS installation.
1.3 To the Infrastructure Team
The EMS infrastructure provides a wide array of administration, routing, security, reliability, load-balancing and fault-
tolerant features. The EMS servers also provide JNDI access for connection factory and destination definitions. The
setup of the EMS infrastructure will predicate the capabilities exposed for JMS and messaging interaction. In some
cases, the EMS infrastructure is controlled through the JMS message (for example via the header properties) or
through the administration interfaces. There are multiple configurations and controls available for the EMS
infrastructure. Performance, scaling and availability can be controlled through the infrastructure and are essential as
part of the design and architecture of the JMS applications.
JMS does not define the infrastructure as part of the specification; therefore, many of the capabilities of the EMS
infrastructure are unique to TIBCO. Since JMS infrastructure is not defined by the specification, it is unique for each
vendor, and, therefore, no common documentation is available.
7
The EMS infrastructure does not require that non-standard extensions provide the capabilities exposed through the
infrastructure, and can therefore, generally, be configured without extensions required in the application.
EMS also supports configurations for JMS messaging that are not covered by the specification, for example, high-
performance reliable-only communications. While these affect the communications paradigm, they do not affect the
JMS specification and source-code interoperability.
1.4 To the Best Practices Guru
Understanding of the JMS specification is only the beginning of understanding the unique capabilities and
configurations and architectures available with the EMS product. TIBCO has provided a robust set of features and
capabilities that go beyond the specification for JMS messaging. JMS does not define all the capabilities required to
ensure an industrial strength implementation of JMS-based messaging. Understanding of other vendor implementations
of JMS does not necessarily provide a sufficient background to understand all that TIBCO has incorporated within EMS
to provide an industrial strength JMS implementation.
1.5 How to Use This Document
The best practices for EMS in this document are divided into two broad categories: EMS client best practices, and EMS
server best practices. In many cases, there is overlap of functionality and dependencies between the two categories.
Therefore, there is extensive use of cross-references used within the document.
The topics in each category represent typical tasks or issues encountered in EMS architecture, design, deployment,
and operations, and they are presented independently in this document. Readers of this document are encouraged to
jump to any specific topic directly to obtain relevant best practices. Cross-references indicate where to go to expand or
explain components mentioned in any particular section. The presentation of ideas is also in a logical flow, so its
reading from the beginning may be more applicable to a person less familiar with JMS or EMS.
1.6 Other Sources of EMS Best Practices
TIBCO EMS product documentation (release 4.x) is another excellent source of EMS best practices.
In general, there are many web sites (including the JMS Specification) and professional books providing excellent
information on JMS at various depths. In particular, web sites and books that talk about messaging patterns can also
help application developers to make the right design choices.
8
2 EMS Client Best Practices
There is a wealth of information on how to use JMS to create client applications. This information is available from
publicly available web sites, professional books, or product documentation. As a result, this best practices guide will not
focus on the basic JMS semantics such as JMS message structure, messaging model, and API usage. Instead, this
chapter will focus on various EMS client-side design issues and features that are not well understood by developers.
2.1 Messaging Naming Standard
There are no hard and fast rules for message naming. Message names are used for messages that are either JMS
Topics or Queues. The name is used to place the messaging into the relevant infrastructure destination and as part of
infrastructure message routing. The JMS specification does not specify a recommendation or standard for messaging
names. Therefore, TIBCO has implemented a subject-based addressing scheme for JMS messages that mimics the
robust Rendezvous naming scheme. Since message naming is outside the scope of the specification, the JMS vendors
are free to implement any naming scheme they desire.
Details for recommendations and best practices for JMS naming can be found in Section: 2.2.1.1 JMSDestination
Header Field.
2.2 JMS Messages
Although the transport specification of JMS messages is not defined, the message structure is well defined within the
JMS specification. The message is a combination of automatic, required and optional fields. The optional fields are
either JMS-defined and/or vendor-specific.
A JMS message structure is as follows:
Figure 1 - JMS Message Structure
Unlike a traditional Remote Procedure Call (RPC) mechanism, the same messages can be shared among several
applications simultaneously, potentially with the same department or even at an enterprise level. It is, therefore,
important to apply internal standards and best practices against the message. This will ensure that:
! Multiple copies of the message will not be required to be sent, thereby reducing network overhead
and application complexity
JMS Message
JMS
Header
JMS Properties
JMS
Body
Standard Properties
Application Properties
Provider Properties
9
! reduce or eliminate inter-application dependencies
! reduce or eliminate message rewriting requirements
! reduce the number of message definitions
! simplify message routing
! avoid vendor lock-in
Ideally, the messages should be created as fire-and-forget objects, regardless if they are created for use with topics or
queues (topics and queues be will discussed in more detail later in this document), but with bridging the queue
paradigm also changes. This is a mindshift from traditional client-server development. It is important to overcome the
traditional RPC design with many objects used against tightly coupled applications. MOM architectures allow
applications to efficiently share data in loosely federated designs. To ensure that this capability is exploited, the
messages must be created in a fashion that is different from traditional client-server designs.
Details of JMS message design will be explored in this section of the document.
2.2.1 Use of Message Header Fields
The JMS message header is used to route messages between endpoints. There are ten fields available within the
header, but not all are required. The JMS header is clearly defined by the JMS Specification.
2.2.1.1 JMSDestination Header Field
This is the Queue or Topic name. This is a significant field. Unlike a client-server message, where the
destination is translated to a socket and an IP address, with JMS the destination is a label on the message.
The label serves two purposes: it provides information about the data contained in the message, and is used
as part of the routing of the message. The destination label can be a combination of the routing and content
information. The JMS destination should not be used to transport actual data. The destination describes the
data or the route. Actual data should be contained in the body of the JMS message.
JMS destinations make use of a subject-based addressing scheme. The destination address is a dot-delimited
string of tokens. It is a freeform field. It is important to carefully consider a complete addressing scheme. As
with assignment of IP address and subnets, if there is no strategy created prior to deployment it can cause a
great deal of administration headache and redesign as the environment expands.
When a JMS message producer creates a message, it will make use of a fully qualified destination name. The
message producer assigns a destination label, and the message consumers register interest in receiving
messages based on either the fully qualified name or a name with wild cards. The destination name is also
used as part of the infrastructures access control system, access inheritance and administration. The
destination label is also used for internal message routing, where wild cards are also used to simplify routing
administration. These additional name-related infrastructure requirements should be considered when
designing a destination name.
TIBCO also supports dynamic destinations. Here destination names and applicability of wild cards is very
important (see Section 2.4 Temporary, Dynamic and Static Destinations for more details on dynamic
destinations).
There are two wild cards available. The first is a token-level wild card, and the character used is the *. It is
used to wildcard a particular field within a destination name. The second wildcard character is a >. This
wildcard is used to match one or more trailing fields. (More details on wildcards and their application is
available in the TIBCO JMS Users Guide)
10
There are no hard rules for the creation of destination names. Some guidelines should be considered:
! The wide-grain wildcard matches trailing characters; therefore, hierarchical label significance is from
left to right, with the left-most tokens being the most significant. For example, if destinations are
geographically significant then a label would possibly be organized as:
country.state.city.street.floor.office
Or as descriptive hierarchy organization as,
country.market.instrument
In this way, it would be easy to create message subscription interest or administrative control with a
single wildcard based on the granularity of message interest.
! Destination labels can be a mixture of multiple label groups, for example geographic, descriptive and
organizational.
! The length of the label will directly affect the size of the message. For performance purpose and to
ensure network-friendly access, it is recommended to limit the size of the destination label.
! In many cases, the source of the message can be included in the destination label. If this is used, it is
recommended to place the source at the beginning of the message. For example, if this is inter-
department messaging, the source department is placed in the left-most field.
! Avoid designing names that require extensive use of single-token wildcards. If required, place the
fields at the left-most position, as mentioned in the previous point.
! Avoid naming schemes that are a combination of required positional fields and free-form fields.
! Although naming would appear more significant for topics than for queues, the administration of the
queue for infrastructure requirements is also simplified through the use of wildcards, and therefore,
considerations for naming of queues is still significant.
! For static queues and topics, it is recommended that the name be retrieved from a central JNDI
repository rather than hard coded into the application or loaded from a configuration file.
! Some corporate-wide prefixes or standards are recommended that can be applied when message
routing is required across a corporate backbone.
! Destinations should be created that will avoid sending the same data more than once. Note that in
some cases message bridging can avoid message duplication from the ingress source of the
messaging chain (see Section 3.4.2 Destination Bridging for details on message bridging).
A metric for the quality of the application design will include a robust message destination scheme that allows
simple wildcard name masking and single messages servicing potentially several downstream applications.
2.2.1.2 JMSDeliveryMode Header Field
This field is set by either the publisher or sender to determine if the message should be persistent or not be
persistent. Persistence implies the messages are available for recover after a failure of the server; therefore,
they are written to disk. With EMS, if there are no durable topic subscribers, the messages are not written to
disk regardless if persistence is set in the header. In this case, persistence is not required, and, therefore,
11
performance is improved by eliminating the disk I/O. This EMS behavior is consistent with the JMS
specification.
It is important to note that the default is the most efficient delivery mechanism, which is non-persistent, but this
also means there is no guarantee for the delivery of the message. If persistence is required, it must be set.
Also, note that persistence is in reference to server failure and not client failure. See Section 2.10 Client Fault
Tolerance for details on client failure recovery.
The infrastructure can employ two modes to persist the messages. The default is to make use of the operating
systems standard buffered writes. Unfortunately, there is no guarantee the last message will be written to disk
since, for performance reasons, the operating system buffers the writes data before actually being written to
disk. EMS also supports a failsafe mode for disk writes. This setup of the infrastructure bypasses the operating
system buffered writes and forces the write to be un-buffered. This is controlled by the EMS infrastructure
configuration for the destination. It is important to note that this slows performance and is a limitation of the
disk drives.
Increase in the performance of the disks will improve the performance of the messaging infrastructure. Disk
performance can be improved with RAID and disk stripping. The synchronous writes used by failsafe mode
can also be improved with buffered and battery backed-up controllers.
2.2.1.3 JMSExpiration Header Field
It is important to ensure that undelivered messages do not necessarily take up resources forever. In addition,
from a design perspective, some data has no value if it is older than a certain period. Therefore, this time-to-
live (TTL) value can be set to expunge the data from the active queue or topic. By default, the value is 0 and
will have the message persist forever. It is recommended that this default value not be used in a production
environment.
It is possible to still preserve these messages even through they have been removed from the active topic or
queue (see Section 2.2.2.1 Provider-Specific Properties).
2.2.1.4 JMSPriority Header Field
JMS specifies 10 levels of delivery priority. Messages with a higher priority will be placed at the front of the
FIFO queues. It is important to note that this will affect applications where message sequence is important.
Architecturally, it is tempting to send priority messages as part of an in-band signaling mechanism. This is not
necessarily recommended. In many cases, a separate queue or topic and asynchronous message
consumption should be used as an alternative to message priority for signaling and alerting.
It is also important to note that system level messages are available through the $sys.monitor topics. Please
refer to the TIBCO EMS Users Guide Appendix C and Section 3.6.4.7 Monitoring Server Events through
Topics for more details.
2.2.1.5 JMSMessageID Header Field
This field holds a unique ID for each individual message. The JMS specification recommends that for
performance reasons, the Message ID be disabled. It will make the message smaller, and does not require the
generation and insertion of a message ID if disabled. Nevertheless, it is important to note that the ID is still
significant within the messaging infrastructure; for example, an administrator can manually delete messages
from a queue based on the ID.
It is recommended that the ability to enable or disable message IDs be exposed through an administration
interface if the application designer has determined that the message ID is not required. In this way, it can be
12
enabled, if necessary, while the application is running or at startup even if it was disabled as part of the
application design. This ID may not be required in production, from an application perspective, but there may
be a requirement for this ID within the infrastructure or administration context, and this should also be
considered as part of the application design.
2.2.1.6 JMSTimeStamp Header Field
Timestamps are created and delivered as part of JMS header as the default behavior. From a performance
perspective, this can be disabled. Unless required, it is recommended to disable timestamps. In addition, from
a design perspective, it is recommended to expose the use of timestamps through either a management API
(for example Hawk instrumentation) or through a startup configuration to ensure it can be used when
necessary.
JMS does not specify when the timestamp is set. The producer can set it when the message is handed off to
the infrastructure, or within the infrastructure.
EMS sets the timestamp when the message is handed off to the message infrastructure. Therefore, it is
important to note the message may actually be sent after the timestamp is set.
2.2.1.7 JMSReplyTo Header Field
This is set as part of a request-reply communications session. Please refer to Section 2.4 Temporary,
Dynamic and Static Destinations and Section 2.9 Synchronous and Asynchronous Interaction for more
details.
2.2.1.8 JMSCorrelationID Header Field
This field is set in the header as an optional field when the message is created. It is generally used within the
context of a request-response mechanism (See Section 2.9 Synchronous and Asynchronous Interaction). It
is this field that should be used to provide user-controlled IDs.
It is also important to note that the correlation ID is also exposed for use within the message infrastructure.
Therefore, it may not be required within the context of the application design, but it may be required as part of
the message tracking or administration. By default, it is not used, but as mentioned for other optional header
fields, it should be exposed through an administration/monitoring interface to provide the capabilities when
required, even if it is not defined for use within the application processing design.
2.2.1.9 JMSMessageType Header Field
This field is set by the application. JMS supports several standard message payload types, including: Text,
Map, Byte, Stream and Object message types. However, this field is misleading since it has nothing to do with
these message types. The producer application, irrespective of the actual message type used, sets the
JMSMessageType value.
It is also possible to use this field with a non-standard message payload. To assist in extending new message
types that are outside of the JMS specification, vendors generally use this field to help process the non-
standard message payload. For example, if a vendor provides a non-JMS method to directly create a type
XML message payload, it would require setting a type in the header to indicate to the consumer that the
message payload is non-standard. While there may be some advantages to this type of mechanism, it is not
recommended since it will create vendor tie-in and prevents potential interoperability with other JMS vendors.
It is still recommended to label the message payload type. This is valuable for applications where the message
may require transformation of the message from one transport standard to another (for example between JMS
and Rendezvous).
13
It is also recommended for XML messages that are transported as standard text payloads where this field may
be used to reference the XSD or DTD that the message conforms to.
This is also a valuable reference field if the client wants to reference message types or message versions.
2.2.1.10 JMSRedelivered Header Field
This field is set by the infrastructure. If a message is not acknowledged in a timely fashion, the infrastructure
may attempt to redeliver the message. If the value is set to false, the consumer is assured this is the first time
the message has been presented. If the value is true, then it is possible the consumer has already received
this message.
If message duplication is prohibited, it is necessary for this field to be monitored by applications. While the
JMS specification outlines the requirement to ensure no duplicates, it also requires application participation for
this to occur. For example, the EMS infrastructure may have delivered the message to the application, and the
application completed processing but failed before the JMS acknowledgement was sent to the EMS server.
Therefore, on restart the client would receive the same message that it processed, but it would be flagged that
it was redelivered through this header field. It is up to the application to react to the fact there was a redelivery.
2.2.2 Use of Message Properties Fields
Message properties are additional extensions to the header that are optional. The JMS Message interface
provides several accessor and mutator methods for manipulating message properties. The property values can be
one of several primitives, including: string, Boolean, byte, short, integer, long, float or double. Properties are
essentially name-value pairs that are added to the message.
The properties can be set either by the infrastructure (i.e. automatically) or by the client.
2.2.2.1 Provider-Specific Properties
The JMS specification provides for vendor-specific message properties. These must begin with the prefix
JMS_. Therefore, all EMS-specific properties begin with the prefix JMS_TIBCO. There are two major
groups of provider-specific properties used by TIBCO. The first group is set automatically, and is generally part
of the message integration between TIBCO JMS and Rendezvous message systems. The TIBCO Rendezvous
related message properties are set when the message is imported by EMS for distribution to JMS clients.
These fields can be used by the application to ensure there is knowledge within the application to indicate the
originating message was not JMS-based. The fields that are set on import as:
! JMS_TIBCO_IMPORTED This is a Boolean variable to indicate if the Rendezvous API created the
original message.
! JMS_TIBCO_MSG_EXT This is a Boolean variable to indicate this is a hierarchical JMS message.
This is a significant property, because JMS does not support a hierarchical message format (i.e. the
message can contain a field that in itself is another complete message). This is an extension provided
by TIBCO. The Rendezvous hierarchical message is mapped into a special JMS Map message,
where one of the fields in the JMS message is another complete Map message. To ensure complete
JMS compliance, it is necessary to avoid using the TIBCO JMS message type extensions. From a
Rendezvous perspective, this is possible by either mapping the Rendezvous message to a compliant
JMS message format prior to import through the EMS server, or making use of the AE_XML message
format, as supported through TIBCO adapters, adapter SDK or products such as TIBCO Business
Works.
14
! JMS_TIBCO_CM_PUBLISHER This is the unique CM correspondence name used by a RVCM
message producer message that was imported through the EMS server to become a JMS message.
! JMS_TIBCO_CM_SEQUENCE This is the unique CM sequence number used by a RVCM
message producer message that was imported through the EMS server to become a JMS message.
It is important to note that the properties that are set when EMS imports Rendezvous messages are not
controlled by the RV sender, but instead set by the EMS daemon. In addition, when JMS messages are
exported to Rendezvous, all non-null JMS properties are put into the JMS messages under the JMSProperties
sub-message, where the Rendezvous field labels correspond to the JMS field names. Setting up the EMS
daemon to configure the transport property export_properties to false can turn off this JMS properties export
to Rendezvous message feature.
The second group of JMS properties is set to control a variety of directives. These directives are instructions
for extensions to the JMS specification. These extensions include:
! JMS_TIBCO_COMPRESS This is a Boolean property set by the message producer. It is to indicate
that the message body should be compressed before it is sent to the server. This property is set
against individual messages. The intention is to compress the payload of large messages to reduce
the disk space required for persistent messages. Enabling compression will slow the process of
sending messages. It also has little value for small message payloads or messages that are not
stored to disk. However, it will help in situations where there are many large persistent messages
being produced.
! JMS_TIBCO_MSG_TRACE If this property is set the message is traced from producer to
consumer. Tracing will be described in more detail in section Message Tracing.
! JMS_TIBCO_PRESERVE_UNDELIVERED This is a powerful directive to inform the infrastructure
to place messages that have expired (see Section JMSExpiration Header Field) into a special
queue called: $sys.undelivered. It is important to create applications to process these messages
from this special queue. Alternatively, the queue can be inspected and messages deleted through the
administration interface or through applications created with the administration API. This is a Boolean
property.
! JMS_TIBCO_MSG_EXT This is set if the TIBCO message extensions are used. JMS does not
support a hierarchical message. To allow a series of nested messages, TIBCO has extended the
JMS specification to allow the insertion of a MapMessage into the field of another MapMessage
and the use of arrays and other primitive types for values. See the previous page for more details on
this property.
The first three properties mentioned above are set to indicate the processing behavior of the infrastructure.
Developers may use these freely in their design without concern. Although these are non-JMS properties, they
will be ignored in other vendors implementation of JMS. They provide vendor-specific enhancements without
jeopardizing interoperability at the source-code level. They essentially provide processing directives to the
infrastructure, and, therefore, will not affect JMS integration or interoperability of producer or consumer
applications. The intention of the JMS message vendor-specific properties is to allow the JMS API to provide
interaction from the application to the vendor-specific infrastructure.
Designers are recommended not to use TIBCO message extensions for use when source code interoperability
is required. Although a more complex payload can be accomplished, this will only operate within an EMS
environment. There will be no interoperability with other JMS vendors with these message payloads. Again,
15
this is more useful when there is a translation between TIBCO JMS and Rendezvous, which does not
necessarily apply with all customer installations. If message payload extensions are required, be aware they
will only work in a TIBCO JMS environment.
As mentioned above, there are architectural alternatives to making use of TIBCO message extensions. These
alternatives include AE_XML message format and pre-mapping the RV message before import into the EMS
daemon, or post mapping after export.
There are two additional TIBCO-specific properties, and they are related to security:
JMS_TIBCO_DISABLE_SENDER This is set if the username of the message sender should not be sent in
the message. The administrator can override this property. Please refer to the TIBCO EMS User Guide for
more details.
JMS_TIBCO_SENDER This is a string field set by the infrastructure to include the client ID in the message.
The client ID is sent by the application when it binds to the infrastructure. The client ID is cached in the
infrastructures EMS daemon. The administrator, regardless of the previous property setting, controls the
creation of this property.
This is a powerful extension for JMS. JMS does not provide any security capabilities beyond a polymorphic
connection method that includes a version of the method that supports the sending of a username and
password (more of this topic is discussed in Section 2.6.1 Infrastructure Authentication). TIBCO EMS allows
the authenticated identification to be passed to the consumer. In this way, it is possible for the consumer to be
able to determine the authenticated ID for the producer of the message. Because the server injects this
property into the message, it is impossible for the producer to masquerade as another ID since they have no
control over this setting. Their authenticated client ID is used by the infrastructure.
The use of this property is again provided through the infrastructure, and will, therefore, not affect non-TIBCO
JMS applications. It is possible for designers to make use of this security extension without concern for source-
code interoperability.
2.2.2.2 Optional JMS-Defined Properties
There are nine optional JMS properties that are defined by the JMS specification. Because they are defined as
optional, there is no requirement for them to be implemented by the JMS vendors. They are identified as other
JMS properties that begin with the prefix JMSX.
Vendors must support only two optional JMS-defined properties (a bit of an oxymoron). The two required
optional properties that must be vendor-supported are JMSXGroupID and JMSXGroupSeq. These
properties are used to assign messages to a logical group, and to have a sequence number against messages
assigned within the group. The client sets these properties against the message. They are supported by the
selector functions. More details on selector functions can be found in 2.2.2.4 Message Selectors.
2.2.2.3 Application Properties
The client sets application properties. These are essentially name-value pairs that are included in the JMS
properties header. Unlike the provider-specific or the JMS-defined properties, there are no restrictions on
these properties. Once received by the consumer, they are read-only values. If the consumer needs to resend
the message it has just consumed, it can either send the current properties, or it must delete all properties and
re-create new ones. It is not possible to remove or change individually consumed properties. This is significant
for use with destination bridges (see Section 3.4.2 Destination Bridging).
16
2.2.2.4 Message Selectors
One of the main purposes of the JMS message properties is to apply filters against the message properties.
The filters are applied against the header and properties. JMS refers to these filters as message selectors.
Message selectors are filter statements that are based on the SQL-92 conditional expression syntax. A
discussion for the details of creating the filter statements is beyond the scope of this document. Many good
reference books have been written on JMS and include the details and examples of the syntax of selector
functions.
The selector function transfers the filtering work from the application to the infrastructure. This infrastructure
filtering reduces the processing overhead from the application. However, it should be noted that this increases
the processing overhead on the messaging infrastructure! JMS makes use of selector functions within
consumer applications.
There is a trade-off in performance using selectors. The processing overhead cannot be removed, merely
shifted from the consumer to the infrastructure. Since the infrastructure is a shared resource among
applications, saving processing overhead in the consumer by using selector functions may result in decreased
performance of other message consumers because of the overhead incurred by the shared infrastructure (i.e.
the EMS daemons).
There are benefits in using the selector functions. For example, a device may have limited processing
capabilities or bandwidth restrictions, and the selector could restrict the number of messages sent to the
application based on the content of the message header and properties. Selector functions are also useful
when used in conjunction with queue browser functions.
However, it is recommended that designers restrict the use of selector functions. This ensures that the
processing overhead on the infrastructure is more deterministic, which provides a less brittle design. This
applies to EMS and other vendors of JMS infrastructures. Selectors introduce a complex unknown into the
performance monitoring and capacity planning of the infrastructure. Selectors also imply the use of message
properties, which also increase the size of messages resulting in more protocol overhead and use of network
resources.
In many cases, (but not necessarily all cases) a better topic destination-naming scheme would provide the
same capability afforded by selectors. Again, the importance of a proper naming scheme cannot be
overlooked (see Section 2.1 Messaging Naming Standard for more details).
If the payload of the message contains data that will require a selector function, then it must be duplicated in
the message properties. This is not very efficient.
If a selector were not utilized, the consumer would be required to examine the message before it determines if
it should continue processing the message or discard it. This can be accomplished directly against the content
of the message, properties of the header, without payload content being duplicated in the properties. This is
not necessarily a high processing overhead operation, unless the processing device has limited processing
capabilities. In many cases, this also may be a viable alternative to using selectors.
If it is determined that a selector is required, it will require prototyping and benchmarking to determine the
impact on the infrastructure. Selector functions can be simple or complex, and there is no hard-and-fast rule to
determine their impact on performance or system resources. It will also require greater scrutiny in monitoring
of the infrastructure servers that are processing the selector functions.
Selector functions are also used in the routing of messages within the EMS server infrastructure. They are also
available for use in the bridging functions. Again, the use of selector functions should be examined in detail. In
17
many cases, a more robust destination-naming scheme may eliminate the need for selectors. More details of
selector use in the infrastructure can be found in Section 2.2.2.4 Message Selectors.
Architecturally, the use of selectors can be isolated to ensure a more deterministic processing model, and will
be discussed as part of the routing design alternatives. However, even these architecture alternatives have
trade-offs in cost, performance and administration management.
2.2.3 Message Payload Types
JMS supports several message types. They are described in detail in the TIBCO EMS Users Guide and most
JMS reference documentation. TIBCO supports all message types defined in the JMS specification.
It is important to note that the message payload, just like message properties, is always read-only when they are
received. Attempts at modifying a received payload will result in an exception being thrown by the application.
The simplest JMS message type is the TextMessage, which is essentially nothing more than a message of Java
String type. It is useful for transport of any string message. It is also useful for the transport of XML messages over
JMS.
At the other extreme is the ObjectMessage. This JMS payload contains a serialized object. Generally, this payload
type only supports applications that were written with the same language bindings. The EMS infrastructure
supports several language bindings other than simply Java. Although ObjectMessage is supported by all EMS
language bindings, the object is only available for processing by applications written in the language that created
the ObjectMesage. When using the .Net Compact Framework, there are even more restrictions on the
ObjectMessage. A full .Net MessageObject cannot exchange ObjectMessages with .Net Compact Framework
application.
For design purposes, the MapMessage payload type would provide the most robust message. This is essentially a
list of name/value pairs, similar to a TIBCO Rendezvous message, but not quite as robust. The name is always a
string primitive. The data is always one of Javas standard primitives or its wrapper. A separate method is used to
read and write the required primitive type for a JMS MapMessage. This adds a degree of complication in the
design since the message producer and the message consumer both must have exact prior knowledge to the
format of the MapMessage. This becomes more complex when Java byte or byte array primitives are used in the
creation and consumption of messages. It is important to note there is no significance to the order the values are
added to the message, and there is no guarantee the order is preserved when enumerated by the consumer.
TIBCO also supports MapMessage extensions. Please refer to 2.2.2.1 Provider-Specific Properties for more
details.
If it is necessary to read primitive data types from the payload in the order they were created, this can be
accomplished using the StreamMessage type. Unlike the ByteMessage type described below, the
StreamMessage writes both the information type as well as the actual message. The StreamMessage payload
also enforces strict casting rules. For example, you cannot read a long if it was originally written as a short
(which is not the case with ByteMessage payloads). If there is an exception thrown while reading the value from
the StreamMessage, the pointer in the stream is not reset, but, for programming convenience, stays at the position
prior to the exception thrown by the last payload read.
As mentioned above, the StreamMessage type is not the only mechanism available to carry primitives. It is also
possible to carry an array of primitive bytes in a JMS payload. This is accomplished using the ByteMessage JMS
payload type. This message type is used when the transport is used to simply move opaque messages between
two applications. For example, the corresponding write method could be used to add a string, an integer and a
18
character to a ByteMessage. The consumer would extract the relevant byte type from the ByteMessage by simply
using the relevant ByteMessage read method (e.g. readChar(), readInt(), readUTF(), etc.).
EMS supports all the supported payloads as outlined in the JMS specification. As noted in Section 2.2.2.1
Provider-Specific Properties, the TIBCO hierarchical message extension should be avoided with JMS message
designs. This will ensure source-code interoperability.
As mentioned in Section 2.2 JMS Messages messages should be designed as fire-and-forget objects. While this
is not always possible, this is a good design technique for MOM-based architectures. Producers of data should
create messages that contain the entire data available, label the data, and then either send or publish the
message. If several downstream systems require overlapping data, then the union of the data requirements
should be sent as a single message rather than as multiple messages with overlapping data elements.
Message payloads design should be focused on creating as few messages as possible, and capturing the
requirements of current and potential future downstream applications to ensure composite messages are sent
rather than multiple discrete messages targeted at unique downstream applications.
While this payload design philosophy may appear to be more relevant to topics than queues, it is still possible that
the infrastructure is used to bridge from queues to topics or vice versa, and, therefore, the design is still valid and
should be used with queue design as well as topic message designs.
From an efficiency perspective, sending fewer larger common messages is more efficient than sending a higher
number of smaller, uniquely targeted messages. However, that does not mean that message size should be
ignored, since this will affect message serialization and marshalling. Message size also affects network bandwidth
utilization. For this reason, sending XML messages may not be the best choice for a message payload. The
tagged text structure of XML can greatly expand the message size.
XML payloads also increase the processing overhead of the consumer. Validating an XML message against a
DTD or XSD and then parsing the message and finally extracting the relevant data is more complex and
processing-intensive than using the JMS payload methods to directly extract relevant data from a payload.
XML messages are generally found to be valuable in situations where the message volume is low and the data is
moved from one processing environment to another, for example in B2B applications. XML messages also provide
a hierarchical and/or complex message payload without making use of non-standard vendor payload message
types (this assumes the XML message is transported as a JMS text message payload and not a vendor-specific
XML payload).
XML is still an excellent way to document and reference JMS message payloads. TIBCO also makes use of XML
definitions to create JMS message schemas using tools such as TIBCO Adapter SDK .
Application designers should also consider making use of the JMS header JMSMessageType (see Section
2.2.1.9 JMSMessageType Header Field). This is an excellent way of referencing message versions or types.
2.2.4 Message Wire Formats
JMS does not specify a wire format for the JMS messages. All messages are transferred in vendor-specific wire
formats. As a result, two different vendor JMS implementations cannot natively exchange messages. For two
vendors to exchange messages requires the creation of an application bridge. These application bridges are
generally a JMS client application that imports the JMS Java connection factory and initial context libraries from
both JMS vendor applications. In this way, it is possible to consume a JMS message from one vendors JMS
infrastructure and then produce the same message in the other vendors infrastructure.
19
TIBCO also supports several wire formats for its adapters and for the TIBCO Adapter SDK product. Included is the
aeXML message format. This wire format can be used with either TIBCO Rendezvous and/or TIBCO EMS for
JMS messages. It is the preferred wire format for JMS interactions via the Adapter SDK. The control information,
when used with the JMS transport, is added as JMS application properties, and the message is sent as an XML
string as a JMS TextMessage message (see Section 2.2.2.3 Application Properties for more details on
TextMessage). Any JMS message consumer can consume these messages since the wire format is the EMS wire
format. Control and message payload are simply JMS application properties and an XML message payload.
2.2.5 Message Compression
Message compression is a unique feature of TIBCOs JMS infrastructure implementation. It is controlled through
the setting of a JMS message property. More details on message compression can be found in Section 2.2.2.1
Provider-Specific Properties.
2.2.6 Message Encryption
The JMS specification does not define security for JMS. Messages can be encrypted by any mechanism defined
by the JMS vendor. The messages can be encrypted at the message level or at the channel level. The secure
channel encryption for messages is provided as part of the TIBCO JMS implementation and the EMS daemon.
EMS provides a secure channel within the context of the JMS messaging through SSL. EMS provides SSL
capabilities at three levels:
! between Applications and the EMS server;
! routes between EMS servers;
! between Fault-Tolerant Servers.
The SSL interaction and setup is controlled through the JMS infrastructure via the EMS daemon.
Authentication is still required over the SSL link. The SSL Distinguished Name (DN) can be used as the principal
(user) name. The administrator, as part of the main EMS server configuration, controls this feature. There are two
ways it can be implemented. The first is when the DN is used for the username in every case, as defined when the
EMS daemon configuration ssl_use_cert_name parameter is set to true. The second alternative is that the DN
name is only used when a specific username is passed as an argument in the createConnection() method. The
username to trigger using the DN name is defined in the EMS daemon configuration file as the parameter
ssl_cert_user_specname.
Many parameters can be adjusted to support the SSL connection and PKI certificate. Details can be found in the
TIBCO EMS Users Guide.
Because SSL is not defined within the JMS specification, it is not necessarily portable to other vendor
implementations of JMS. Within JMS, the SSL parameters required to negotiate an SSL connection are specified
as part of the destination connection factory. The connection factory can be called from the JNDI store or can be
created within the application. When created in the application, the SSL parameters are passed as a hash table to
the standard factory constructor. The connection factory is the mechanism provided within the JMS specification to
provide access to the vendor-specific implementation of destinations. Therefore, the EMS implementation of SSL
will not result in vendor lock-in; it just may not be portable to other vendor implementations that do not support
SSL or PKI.
It is important to note that SSL is processing-intensive and will affect performance and throughput. Hardware
accelerators are available to offload some of the performance impact of the SSL protocol, and should be
20
considered by designers if extensive use of SSL is considered for a particular application. TIBCO has tested and
certified multiple models of the Ingrian Accelerator. Please refer to the TIBCO EMS User Guide for more details
and the Ingrain documentation.
SSL with channel encryption is not the only mechanism available to encrypt messages. Encryption can also be
controlled through the application, and not just through the infrastructure with SSL.
As mentioned above, a complete security policy cannot be implemented within the JMS infrastructure; nor is it
expected or defined at this level as part of the JMS specification. There are other security requirements that are
implemented at the JMS application level, and not necessarily at the infrastructure, level. The JMS specification
does not outline security requirements for JMS, but Java does implement a security infrastructure for applications
against which JMS applications are expected to take advantage.
For authentication, Java defines JAAS as a PAM-base architecture, which is implemented as follows:
JAAS is only a part of the complete security application story available with Java. The complete application
security story is as follows:
Java-based JMS applications making use of JAAS, SASL, GSSAPI, Kerberos, etc will be provided with a security
model that is targeted between JMS applications and not necessarily between the JMS application and the
infrastructure.
Applications can authenticate themselves through the Java application model, but it was designed between
applications, not between the application and the infrastructure. It is possible with EMS JMS applications to have
the application obtain credentials through JAAS and Kerberos and then use those credentials to authenticate the
21
application to the infrastructure. This requires the application to provide SASL access to the LDAP server and the
ability to create a new ephemeral password at connection time.
Use of JAAS, GSSAPI and SASL operates correctly within the EMS infrastructure.
It should also be noted that with the exception of JAAS, all other Java support for standards such as GSSAPI,
SASL and Kerberos are also available for binding with languages other than Java; including C and C#.
2.3 Queues vs. Topics
There are two major models for messaging supported by JMS: queues and topics. Queues are based on a point-to-
point messaging model. Topics make use of the new publish-and-subscribe messaging model.
Regardless whether queues or topics are used, the messages are not sent directly peer-to-peer. Messages are
forwarded to a JMS infrastructure that is composed of one or more JMS servers (EMS daemons in the TIBCO product
implementation). The servers are responsible for providing the quality-of-services to JMS and responsible for
implementing all the components not addressed by JMS as described in Section 1.1 EMS Development Background.
Infrastructure components are vendor-specific implementations. Regardless of the vendor, all base implementations are
similar to the EMS implementation as follows:
The JMS specification defines the API for both the Message Consumer and Message Producer. The vendor defines the
transport of the messages and the server infrastructure, in this case the TIBCO EMS server.
The key to the design of the messaging infrastructure is not just the best practices in the use of the JMS specification in
the creation of message producers and consumers, but also in the design and implementation of the infrastructure.
Further discussions of JMS queues and topics will, therefore, focus on the infrastructure to support queues and topics
rather than on the creation of producers and consumers that make use of the infrastructure.
The TIBCO EMS infrastructure is based on the same server (daemon) process, regardless if the topic-messaging or
queue-messaging model is deployed. However, although there is some overlap, there are differences in the architecture
of the EMS server processes to service queues and topics. Each will first be discussed individually.
JMS queues are used to implement a point-to-point messaging model. Any number of message producers can put
messages into a queue, but only one consumer can remove messages from a queue. While it is possible to have more
than one consumer connect to a queue, only the first consumer will actually be able to process messages from the
queue.
It is possible to implement non-exclusive queues. This allows more than one consumer to connect to the queue and
consume messages, but once a non-exclusive queue consumer consumes a message, it is no longer available for
Message
Consumer
Message
Producer
Message Message
EMS
Server
22
processing by any other non-exclusive queue consumer. This is the mechanism used to provide a scalable round-robin
processing of JMS queue messages.
Processing order of messages is guaranteed through a JMS queue. Messages are placed in the queue even if here are
no consumers for the message, in a fashion similar to pre-registration with RVCM.
Topics are used for publish and subscribe message models. There is no concept of pre registration for topics (i.e. the
capability to save messages for consumers that start after the producer starts). If there are no active consumers for a
topic, no messages are placed in the topic even through there are topic message producers. Unlike queues, topics
support more than one consumer. Durable topics subscribers ensure the message is still available if a register
consumer fails and restarts.
Both queues and durable topics support message persistence. With persistence, the messages and state metadata are
saved to disk to ensure the message is available in the event of a EMS daemon failure.
Both queues and topics support both synchronous and asynchronous processing of messages (see Section 2.9
Synchronous and Asynchronous Interaction for more details).
2.3.1 EMS Queue Infrastructure
Queues are the mechanism used to provide point-to-point messages between consumers and producers of
messages. Rather than using a peer-to-peer model, as with traditional client-server models, JMS makes use of a
store-and-forward model. This allows the server infrastructure to provide services that are not available in a peer-
to-peer model.
This Section of the document will describe the EMS server features that are available to provide transparent
service to JMS endpoints.
2.3.1.1 Queue Message Flow Control
Ideally, consumers and producers will constantly be up and available to process messages, but this is not
always going to be the case. If the producer is active but the consumer is down or is failing to keep pace with
the producer, messages will start to build up in the queue on the EMS server. It is conceivable that the
messages would grow in number and eventually overflow the memory or disk, depending on whether or not
the messages were flagged as persistent. Regardless, if the resource of disk or memory is overwhelmed,
because of a problem with the consumer, it could lead to a catastrophic system failure.
It is important that resources do not become totally consumed. Monitoring of the queue-based EMS server is
the first line of defense (see Section 3.6.4 Administration and Monitoring for more details on monitoring). It is
also possible to have the producer set a property to compress the messages (see Section 2.2.5 Message
Compression). This will not only provide potentially better performance for large messages, it will also ensure
that a larger number of messages can be stored before the system is overwhelmed. However, none of these
recommended solutions will ensure the resources are not completely consumed.
EMS provides a flow control system to ensure that memory or disk resources are not completely consumed
because of problems with the consumer. Flow control is set on a per-destination basis, where the administrator
sets the maximum limit for the destination. When the limit is reached, the producer is blocked from sending
any more messages to the queue until the queue is partially emptied by the consumer.
Although each queue destination has control over the size threshold before the producer is blocked, the
administrator still has the ability to enable or disable flow control for all queues associated with an EMS server.
23
It is important for the administrator to be aware of all queues (and, potentially, topics) that have flow control
enabled, since the messages from all are placed in the same file; and, therefore, the sum of all the thresholds
should not be greater than the total disk available or memory available.
While the infrastructure provides some control to ensure that resources do not become overwhelmed, this
should not be the only approach applied to the problem. In some cases, it is not practical to block the producer
of messages. This requires a more proactive solution to the problem.
There are two more alternatives to solving the problem within the infrastructure. The first solution is to architect
a solution where the consumer performance is optimized (this is discussed in the next section). This is a
proactive approach where the problems of consumer availability and performance are optimized to alleviate
resource overflow due to consumer problems. The second solution is to make use of asynchronous alerts
through the management infrastructure such as TIBCO Hawk.
The second approach is to make use of management interfaces within the producer rather than in the
infrastructure. Here, if possible, the producer should slow its rate of message generation if it begins to detect
that messages are building up before the flow control threshold is reached, and the producer should alert the
management system that a problem is beginning to develop
Flow control is set on a per-destination basis, but for ease of administration, this can be applied with wildcards
in the destination names; again, another reason a strong naming scheme is important even with queues (see
Section 2.2.1.1 JMSDestination Header Field).
2.3.1.2 Scaling and Performance Tuning of JMS Queues with EMS
Flow control has been added to the EMS server infrastructure to ensure that resources are not overwhelmed.
Resource utilization only becomes an issue if the consumer is not available or lacks processing scalability.
However, there are architectures to ensure that flow control is the last resort and not the only solution to deal
with consumer performance issues. Providing scaling and performance enhancements as part of the
architecture will ensure flow control is never enforced; except as a last resort.
There are several solutions to provide scaling and performance improvements with JMS queues. Most of these
are not part of the application code specifications or code design; hence, outside of the JMS specification.
Client performance and availability are part of the application deployment and the EMS infrastructure setup
and configuration. The robust nature of the EMS infrastructure, coupled with proper application design,
provides the necessary ingredients to resolve the issue of resource saturation.
There are several mechanisms available to provide better performance for the JMS queue consumers:
! Non-exclusive consumer Only one consumer can remove a message from a queue. If the queue is
non-exclusive, then multiple queue consumers can be started to consume messages from the queue.
This provides better performance since the multiple queue consumers take messages from the queue
in a round-robin fashion. This also has the additional benefit of providing availability as well as load
balancing. This is not an alternative if order-of-message processing is required through the
processing chain. (Note that, in many cases, order of messages through the infrastructure is not
always mandatory since, generally, order of processing can be easily solved through exception
processing but not in every case). This setup is part of the JMS specification and is included to
complete the solutions list.
! Exclusive Consumer With an exclusive consumer, there is no horizontal scaling as in the previous
point, but it is possible to have more than one consumer listening to the same queue for exclusive
access. Only one consumer will actually process from the queue, but should it fail, the second
24
member will immediately be activated to receive from the queue, thereby providing greater availability
for the consumer process.
! Queue Message Prefetch Traditionally, messages are delivered synchronously from the queue to
the server. The next message is not sent to the consumer until the previous message is
acknowledged. EMS supports the batching of several messages to the consumer in the background.
This generally provides better performance than the single-message mechanism. A parameter is set
by the administrator against the queue on the server to enable this feature. The applications are
unaware of this mechanism being employed.
! Expiration As explained in Section 2.2.1.3 JMSExpiration Header Field, it is important to set a TTL
value for messages that do not need to exist forever. If the message only has value for a certain
period, then it should automatically be expunged from the queue if it is not processed in a timely
fashion.
! Fine-Grain Naming If exclusive queues are required (or even in the non-exclusive queue scenario)
then multiple different messages should not necessarily be processed by the same application,
thereby restricting processing to a single consumer. For example, if messages are produced with
three separate countries specified in the message, perhaps the messages should be sent to three
separate queues, rather than all sent to one queue. If it is an order message, then rather than going
to a queue X.Y.Order, it should go to X.Y.Order.Canada. Even if the queues are on the same host
this will allow multiple applications to consume messages, even if it is the exact same application, but
against a separate queue and thereby increase performance and throughput.
! Topic and Queue Bridging Bridging is discussed in more detail in Section 3.4.2 Destination
Bridging. An example of queue scaling is through bridging queues to a topic. The message producer
now sends the message as a topic. A selector is then used to bridge the topic message to the
appropriate queue. This provides a single fire-and-forget message that decouples the producer from
the consumers. Queues can then be created as described above, and the selector on the
infrastructure bridge forwards the message to the appropriate queue. Unlike the previous solution, the
producer does not need to have prior knowledge of the fine-grain queues. Message properties will
need to be employed, and this will cause trade-offs (see Section 2.2.2.4 Message Selectors).
! Reliable Message Delivery Not all messages require the guaranteed message delivery semantics
provided for by the JMS specification. In some cases, a best effort may be acceptable. If this is the
case, it is possible to set the JMSDeilveryMode header field (see Section 2.2.1.2 JMSDeliveryMode
Header Field) to Tibjms.RELIABLE_DELIVERY. JMS specifies a two-way handshake for consumer
acknowledgements. First, the consumer acknowledges the message to server and then the server
acknowledges the consumer acknowledgement. This special delivery mode eliminates the
requirement of the consumer to wait for server (daemon) acknowledgments to the consumer
acknowledgements, and, in fact, the server no longer sends acknowledgements to the consumer
acknowledgements. This decreases message overhead and allows better resource utilization and
better message throughput. This does not affect interoperability since it is an infrastructure directive
that i s i gnored by other vendors. Rel i abl e del i very cannot be set usi ng the
Message.setJMSDeliveryMode() JMS API method.
! No-Acknowledgement Message Receipt This feature is similar to the previous, except the
consumer no longer acknowledges the server, and the server eliminates all information about the
message without explicit acknowledgement from the consumer. This again increases throughput and
reduces system utilization, but messages are not guaranteed. The no-acknowledgement receipt
25
mode is set in the method that creates the session from the connection object. This is a non-standard
setting for the JMS-specified delivery modes. It is important to note that there are two restrictions
when this delivery mode session is enabled:
o Applications cannot create durable topic subscribers.
o Queue consumers that are getting messages from a routed queue transport are not allowed
to specify this mode of delivery.
! Message Tracing and Logging Tracing of messages can cause a significant load on the
infrastructure and it is recommended not to have tracing permanently enabled for production
environments.
! Routed Queues This is a unique feature in the EMS infrastructure. In many cases, especially with
large message volumes, the operating system becomes the bottleneck as it tries to process the
heavy I/O. The only way to overcome the issue is to move some of the queue processing to another
host. This is possible with EMS using routed queues. These are special queues that act as proxies to
the actual queue for both inbound and outbound queue-message processing. Consumers and
producers connect to the proxy hosts or the actual queue server, and all clients operate transparently
as if they are connected directly to the actual queue. This allows the unique ability of horizontal
scaling of queues with all the inherent benefits of horizontal scaling. Note, flow control is only
available on the actual queue, and not on the proxies. See the TIBCO EMS Users Guide for more
details.
! Management Tools System management tools should be monitoring the availability of the
applications and the use of system resources. Thresholds should be set within these tools to alert an
administrator before system resources become saturated. They can also be configured to restart
failed consumers.
! Increasing TCP Send and Receive Buffers Generally, in TPC/IP communications, the default send
and receive buffers are low, usually only about 8K in size. This can affect the performance of the TCP
stream due to the nature of TCPs sliding-window flow control. Increasing the buffer size to 32K or
64K can result in a 5% to 10% throughput increase. EMS supports increasing this buffer size. See
Section 2.10.3 Tibjms Object for details.
! Message Size Message size will affect performance, but this is not necessarily a factor resulting
from the EMS design. There is a requirement of the operating systems to perform Segmentation and
Reassembly (SAR) for the Layer Two protocol (e.g. Ethernet) to send the message within the Layer
Two Media Transfer Unit (MTU) size. If the message and protocol overhead is larger than the MTU, it
requires SAR at the OS-level to split the message into multiple segments, and this is an expensive
operation as far as the OS is concerned. Sending message+overhead smaller than the MTU (which
for Ethernet is about 1500 bytes) will improve throughput performance. Sending larger messages,
where the size divided by the MTU has the smallest modulus, will also provide better performance.
Once the message get to large, the affects of buffering and manipulation will also begin to slow
performance.
One should not ignore the subtle efficiencies afforded at the protocol level, since the performance and the
system resource saving are accumulated across all the messages and will help improve throughput. More
details can be found in the subsections of Sections 2.2.1 Use of Message Header Fields and 2.2.2 Use of
Message Properties Fields.
26
2.3.2 EMS Topic Infrastructure
The use of topics and a publish-and-subscribe messaging model is one of the messaging advances that are
available through JMS. Applications are no longer restricted to making use of synchronous request-reply.
Developers should consider the use of topics as one of the primary alternatives in designing application
messaging infrastructures. The EMS server provides many design alternatives to ensure that the applications are
both scalable and available.
Unlike the queue-messaging model, topics allow multiple consumers to reliably receive the same message. The
server is required to store and forward messages between topic producers and consumers, but the server must
now hold the message until all registered consumers receive the message.
JMS topics also introduce the concept of durable subscribers. These subscribers require the server to accumulate
messages on the subscribers behalf should the subscriber temporarily be unavailable.
It may begin to become evident that the JMS server infrastructure must be more robust for topics than is required
for queues. As a result, EMS supports many features to ensure that the JMS topics are both robust and scalable.
This section outlines some of the capabilities within the EMS and their relation to ensuring an industrial-strength
implementation.
2.3.2.1 Topic Message Routing
While it is possible to implement large topic-messaging models on a single host, there are many reasons why
more than one host will be a more efficient implementation. For example, assume there are 100 subscribers in
London, and the server is in New York. Every time a message is produced in New York it would need to be
sent to London 100 times, and the entire inherent protocol overhead would be duplicated across the WAN 100
times. Not only is this deployment model not deterministic, it is very inefficient.
To overcome the issue of single-server deployment, EMS provides the capability to route messages between
servers. Routing topics between servers provides horizontal scaling for topics. In the example above, a single
server in each city would allow the consumers to connect to the local server. This would not only make the
WAN traffic deterministic (now the traffic is equal to the producer volume and not complicated by the number
of active remote users), but it reduces the traffic and protocol volume to a single data message regardless if
there are 100 or 1000 subscribers. This capability is all predicated on the ability of the EMS infrastructure
servers to route topic messages.
There are two topic routing models available with EMS. Each has its own pros and cons, but provides the
capability to address more efficiently different architecture scenarios. To further enhance the capabilities, both
routing models can be used in the same architecture by allowing the server to make use of both models
simultaneously. The two models are single-hop and multi-hop routing.
Multi-hop routing allows the topic messages to flow between more than one neighbor relationships. It also
detects loops and will not allow a link between neighbors that will result in a loop. Single-hop routing only
allows the topic message to flow to adjacent neighbors. The accepting neighbor will not subsequently forward
the topic message to another neighbor.
It is important to note that the queue routing described in the Section 2.3.1.2 Scaling and Performance Tuning
of JMS Queues with EMS is only applicable to queue messages and does not apply to topics or topic routing.
In addition, the converse is also true; topic routing does not apply to queue routing.
The configuration and administration of routing is transparent to both the consumers and producers, but there
are components defined in the application, such as destination names, that have significance within the routing
27
infrastructure; therefore, routing should not be ignored as part of the design of the producer and consumer
applications.
Topic messages can be routed by simply defining the topic as global. Unless the topic is defined as global
on the server that the producer or consumer is connected to, messages will not leave that server for that topic
(or series of wildcard topics) regardless of other routing settings.
Routes are established between neighbors. Neighbors should be configured to authenticate themselves to
each other and follow access control directives to control the flow of messages between servers. Regardless if
the topic is set to global on the server neighbors, access controls can still restrict the movement of messages
between the servers. Access and authentication between servers are the same as defined between clients and
servers (for more details see Section 2.6.4 EMS Routing Authentication and Authorization). SSL encrypted
links between servers can also be used to ensure privacy of messages between servers.
One side initiates a routed link between servers only (active/passive), or both can be configured to attempt to
connect with each other (active/active). Only the active host specifies the route parameters. Servers can be
both active and passive simultaneously.
There is no setting to make an EMS server passive. Passive hosts will accept connections from any active
host. For this reason, clients must configure the proper access controls and authentication to ensure only
desired EMS servers might connect to the passive servers.
With EMS, servers are arranged in Zones. A Zone is a group of hosts that participate in forwarding messages
in a particular routing behavior. There are two routing behaviors: multi-hop and single-hop. Members of a Zone
can only make use of one routing behavior, but a server can simultaneously belong to more than one Zone.
This section is intended to merely introduce EMS topic routing and a few recommendations for setup. More
details can be found in the TIBCO EMS Users Guide.
2.3.2.2 Topic Flow Control
As with queues (described in Section 2.3.1.1 Queue Message Flow Control) topics support flow control for
durable subscribers. Flow control is applied only against topics that have been configured with flow control.
The mechanism and issues are the same as those described for queues.
Topics expand the deployment of flow-control. Unlike the scenario with queues, the server must hold the
message until all active and/or durable subscribers have received the message. Unlike the queue scenario,
the buildup of messages in the server could be due to problems with one or more consumers either failing or
not being active (this is not only an issue for durable subscribers) or performing poorly.
Topic routing also adds another wrinkle to the flow control issue. When global topics are routed between
servers, flow control can be enabled against the topic on either server or on both. Assume a simple scenario
where the publisher is on one server and the consumer is on the second routed topic server. If flow control is
enabled on the publisher server, then, when the threshold is reached, the producer is blocked from sending
more messages until some of the messages are drained from the topic on the server. If flow control is enabled
on the consumer server, then the producer server (not the actual producer) is blocked from sending more
messages until the consumer drains some topic-messages from the consumer server.
This behavior allows horizontal scaling of resource utilization. Unlike the queue scenario, the topic routing not
only offloads I/O but also allows more than one server to participate in distribution and expanding the threshold
due to slow consumers. This allows administration services to detect a problem that resulted in flow control
before the entire processing chain is affected.
28
2.3.2.3 Durable Topics
In Section 2.2.1.2 JMSDeliveryMode Header Field there was a brief description of the JMS protocol header
that signals the JMS infrastructure if the message should persist in memory or disk for message recovery after
daemon failure. This instruction configuration was to ensure that the messages would still be available after a
failure and recovery of the EMS server.
For topic subscribers, the EMS server holds the messages until all currently registered listeners have received
the message. Should a subscriber fail and restart, the messages delivered while the subscriber was down
would not be available to the subscriber when they finally restart. To overcome this issue, a special subscriber
can be created.
A durable subscriber is a special form of topic subscriber that ensures the EMS server will hold the messages
while the subscriber restarts (or until the message is aged out, see Section 2.2.1.3 JMSExpiration Header
Field for details). A separate JMS method is used to create durable subscribers. It is also important to note
that durable subscribers must explicitly unsubscribe from a topic or the daemon will continue to accumulate
messages, and this may result in a flow-control overflow situation (see Section 2.3.2.2 Topic Flow Control).
The administrator may also manually unsubscribe durable subscribers (or normal subscribers).
To ensure guaranteed recovery, the topic must have durable subscribers, and the producers must set the
message to be persistent. In this way, the message will survive consumer and/or EMS server failure and
recovery. There is no need for durable queue consumers since the nature of queues does not require this as a
separate functionality.
The Session.createDuableSubscriber() method requires a durable name to uniquely identify the application.
The connection for the session for the durable subscriber supports a Connection.setClientID() method. With
EMS, the combination of both of these methods creates a unique identifier for the durable topic subscriber
where the two are concatenated with a colon separator. There must be a globally unique identifier for the
durable subscriber. If a session is created and the identifier is not unique, the new session will be terminated
and an exception will be thrown.
It is recommended that developers use both API methods when creating durable topics. The durable name is
generally set to be the name of the application, and the client ID is the principal name (username) used to
authenticate the application to the EMS infrastructure. It is important that developers recognize the
requirement for a unique reference for the durable subscribers.
Acknowledgement modes are also significant with durable subscribers. If auto-acknowledgement is set, the
message may have been processed, but the server may not have received the acknowledgment before the
client failure. The message would still be held by the EMS server, and would attempt to continue to redeliver
the message after the subscriber restarted. The client would be responsible to ensure the message was not
already processed. The message header would indicate that the server has already attempted delivery (see
Section 2.2.1.10 JMSRedelivered Header Field).
For durable subscribers it may be necessary to enable the use of the message ID (see Section 2.2.1.5
JMSMessageID Header Field), or some other reference for the client to keep persistent reference for the
messages that it has processed to ensure no potential duplicate processing. Also, note that the processing
model may be tolerant to duplicate messages, and that this may not be an issue in those cases. For example,
if the message is written to a database with a unique key field, the database write will detect the duplicate and
allow the application to react accordingly.
Client acknowledgement mode is also available for a more fine-grain control over the acknowledgement. This
is especially important if asynchronous messaging is used where the onMessage() method is executed in a
29
separate thread. With autoacknowledgement, the acknowledgment is sent after the method returns, but if the
method is executed in a thread (a higher performance model of processing asynchronous messages), control
is given back to the controlling application before the method completes execution. This may result in unknown
processing states if the application fails before the method completes execution. Therefore, it is recommended
that, for applications that use durable subscribers and asynchronous messages, that the client-
acknowledgment mode be used, and acknowledgments should be manually sent as the last statement in the
onMessage() method.
It is also important to note that durable topics and persistent queues will have a lower throughput and higher
resource utilization than non-persistent messages. The limiting factor in the performance is the disk and disk
controller technology. Improving disk performance will also improve the message performance. Several things
can be done to improve the performance of persistent durable topics and persistent queues:
! Disk arrays with interleaving across multiple spindles will generally provide better performance than
with single disks.
! Generally, journaling file systems provide better recovery capabilities and performance than non-
journaling file systems.
! Stripping as with RAID will generally provide better performance than mirroring.
! Synchronous writes (as with EMS failsafe mode for destinations) will provide marginally higher
reliability, but may greatly reduce performance.
! SAN will generally provide better performance than NAS or dual-ported RAID arrays.
! Battery backed-up disk controllers (or fiber channel controllers for SAN) will generally allow
improvements for synchronous writes since the controller reliably buffers the data before it is actually
written to disk. The individual vendors must confirm details.
! Message compression will require less disk write and may improve performance and reduce disk
resource utilization (see Section 2.2.5 Message Compression for more details).
! Use of a topic to distribute messages to multiple consumers rather than multiple queue writes will
potentially reduce the number of disk writes required (and network utilization).
! One larger common message for multiple consumers is more efficient than several smaller messages
targeted at fewer consumers.
While persistent durable topics provide a high degree of reliability, there are also drawbacks. Fortunately, there
are architectures and designs that can be employed to optimize the performance while also solving network
and availability issues with the same solutions.
2.3.2.4 Scaling and Performance Tuning of JMS Topics with EMS
Several performance and tuning aspects have already been described for JMS topics within an EMS
infrastructure. The advanced routing capabilities of topics allow scaling the number of servers beyond the one-
hop restriction with queues. Flow control can also be distributed among multiple servers. EMS topic routing
capabilities overcomes bandwidth and geographic problems that may be encountered.
In addition, all except the points about routed queues and exclusive/non-exclusive queues in Section 2.3.1.2
Scaling and Performance Tuning of JMS Queues with EMS also apply to JMS topics and EMS.
30
2.4 Temporary, Dynamic and Static Destinations
JMS defines three types of queues and topics: temporary, dynamic and static. Up to this point, the topics and queues
that have been discussed were static. Static destinations are manually defined in the EMS daemon configuration.
These are referenced in the applications through the creation of the Destination object references to the queues and
topics. They can be referenced through a JNDI interface or through the creation of an application-level reference
Destination object using the Session.createQueue() or Session.createTopic() methods.(see Section 2.7 JNDI Lookup).
Dynamic destinations are an EMS concept. Dynamic destinations are a special feature that are part of the EMS
infrastructure implementation. They are essentially static queues, and topics; but they cannot be referenced through a
JNDI interface, and they only exist as long as there are messages in the destination, or there are consumers
connected. The use of dynamic queues is transparent to the JMS application, and appears as standard application-
referenced static destinations.
As mentioned above, there are two mechanisms to create references to destinations within a JMS application. The first
is through getting the reference from a JNDI-compliant data store. The second mechanism is to use the createTopic()
and createQueue() methods to create the reference against the fully qualified destination name. This predicates that
the application is aware of the fully qualified name and, therefore, has no need to get the reference through JNDI.
EMS infrastructure allows the same methods to create the fully qualified destinations (dynamic destinations) at the time
the reference is requested (assuming the destination does not already exist). These methods are used as an alternative
to using the JNDI-based data store to retrieve destination references; therefore, not being able to get the reference for a
dynamic destination from a JNDI store is not really a limitation of dynamic destinations.
With EMS, applications cannot just create any destination name they desire. The administrator must create wildcard
destination root-names in advance. Applications (assuming they have the correct privileges see Section Application
Authorization for more details) can create sub-topics and sub-queues under the wildcard-defined names. The
destinations will inherit the same privileges and attributes defined for the root destination names.
Dynamic destinations have several advantages over pure static destinations:
! Administrators can delegate a hierarchy of destination names and privileges to applications without
requiring a complete list of fully qualified names for every application everywhere in the routed
infrastructure.
! Provides for potentially both a centralized, distributed, and hierarchical delegation of destination
administration.
! Developers can create and destroy destinations on a well-defined basis without requiring full
administration access or access to the administration API (recall the administration API is vendor-
specific because JMS does not specify the API to administer the infrastructure).
! Better utilization of system resources since the dynamic destinations are removed from the
infrastructure when not required.
! Provide many of the benefits of temporary queues (see below for more information on temporary
queues), without the restrictions.
! Greatly simplifies the administration of destinations.
! The create methods continue to operate against fully qualified static destinations as would be found in
non-EMS infrastructures.
31
The key to dynamic destinations is that they are special static destinations that were referenced with a wildcard as part
of the EMS administration destination name. Rather than administering all fully qualified destinations, the destinations
can be block-assigned and only utilized when, and as long as required.
It is important to note that dynamic destinations is a feature of EMS and is not available with other vendor JMS
implementations. However, because it operates within the infrastructure and does not affect the standard JMS methods
to create destination references for use in JMS applications, it will not affect code interoperability. The other vendor
implementation will merely require the creation of all fully qualified destinations and lose the advantages listed above.
Temporary queues and temporary topics are a special type of destination that is only available for the lifetime of the
session. Temporary queues are always accessible to the application that created them, but they are not directly
accessible by any other application. The only way applications that did not create the destination can access temporary
destinations is through a reference received (consumed) from the producer. The producer can allow the consumer to
write to a temporary destination they created by adding the temporary destination name to the reply field in the
produced message (see Section 2.2.1.7 JMSReplyTo Header Field).
These temporary destinations are meant to operate as part of a request-reply message interaction. It is important to
note that this does not imply that interaction must be synchronous. In fact, asynchronous request/reply is the
recommended mechanism for applications to use. Although it does not apply to all situations, asynchronous
request/reply provides greatest throughput for request/reply message processing.
With asynchronous request/reply it is possible to have the message producer send multiple requests without waiting for
the reply. The reply can then be processed as a separate thread, either by manually dispatching the replies from the
temporary destination, or making use of the preferred callback mechanism within JMS. If it is necessary to co-ordinate
the request with the response, the producer could make use of the correlation ID (see Section 2.2.1.8
JMSCorrelationID Header Field) or the JMS message or group ID (see Section 2.2.2.2 Optional JMS-Defined
Properties).
It is not necessary to create a temporary destination for every request. It is recommended to limit the number of
temporary destinations and to dispose of them when they are no longer required. If a producer is stopped, all temporary
resources are immediately released by EMS.
It is very important to note that there is no value in setting temporary topics to persist or using a durable subscriber
against a topic. The nature of a temporary destination is that it is released if there is a failure of the client, which could
be a result of either a client failure or a server failure. Regardless, there is no way to reconnect to the temporary
destination after the failure since it will be removed as a reference as part of the JMS specification. It is important for
designers to provide the code for a retry request as part of the request/reply application since there is no way for JMS to
guarantee a reply through temporary destinations.
There are also helper classes available with Java JMS to simplify request/reply sessions. The two additional helper
classes are queueRequestor and topicRequestor.
2.5 Queue Browser Usage
JMS supports queue browsing. This is a feature where the message in the queue can be introspected without actually
processing (consuming) them from the queue. This allows the developer to make decisions on how to process current
queue messages, based on other messages further down in the queue. For example, there may be several order
messages in the queue, each with a different quantity. The application may want to process orders to ensure there are
no partial shipments. This is possible through the queue browser. The application will browse the queue to see how
many orders can be processed until the next order will result in a partial shipment. The consumer application can then
process that number of orders. At that point, it can again browse the queue for any order that exactly matches the
32
remaining inventory (or small orders that cumulatively match inventory). It can then consume the queue again, flagging
all other orders as backorder, except the order (or cumulate small orders) that completely drain inventory.
It is important to note that for scaling purposes, EMS supports a unique capability of routing queues. Queue browsing is
only supported on the actual queue, and not the routed queue participants.
EMS also supports the unique capability of dynamic queue browsing. The queue browser method can dynamically
receive new messages that are added to the queue. If the hasMoreElements() method of the browser enumeration
returns false the application can wait and try the enumeration again because, behind the scene, EMS queries the queue
every 5 seconds for any new messages. An example of this capability is included in the EMS sample programs that are
distributed with EMS.
It is important to note that Queue Browser can also be used in conjunction with selector functions. For more details on
selector functions please refer to Section 2.2.2.4 Message Selectors.
2.6 Secure Client Connections
Connections to the EMS daemon require authentication. Based on the user credentials, access to queues and
administration functions are granted. The following outline the authentication capabilities of EMS:
2.6.1 Infrastructure Authentication
One of the only security references in JMS is the concept of authentication. When a connection is created with the
createConnection() method, JMS specifies a method that supports passing simple username (principal name)
and password credentials to the application. On a wide-grain level, it is possible for EMS to turn on or off client
authentication. It is not recommended to turn off authentication.
If the credentials are incorrect, an exception is thrown and the application will fail to bind to the JMS infrastructure.
If the credentials are verified, the application gains access to the infrastructure. Gaining access to the
infrastructure does not guarantee access to destinations.
Validation of the credentials is performed in one of three possible ways:
! Validation with the username and password that are stored locally as part of EMS.
! Validation with the system username and password.
! Validation through an LDAP bind with the username and password (LDAPv2 and LDAPv3)
The EMS username and password local data store is fine for most clients to use in testing and development, but
the system or LDAP versions are recommended for production. The local EMS data store does not enforce
password aging, a requirement for some customers. This can be implemented at the system or LDAP level.
EMS also supports the concept of user groups. It is advised that users be associated with groups since this
simplifies administration. Group information can also be extracted from external LDAP directories.
When a password is sent to the EMS infrastructure, the password is obfuscated so that it does not appear as a
plain-text password in a TCP dump or trace.
It is also possible to allow users to connect to the EMS infrastructure without a username and password. They will
be connected as a user named anonymous. This does not mean that they will have access to destinations. The
administrator must still provide access authority for this unique user ID.
33
Please refer to the TIBCO EMS Users Guide for more details on setting up users and external data store
references.
2.6.2 Administrator Authentication and Authorization
Administrators are a special class of users. There are three classes of administration users with EMS:
! The unique admin user ID that is part of EMS.
! Special group of administrators created by admin.
! Typical application users with limited administration privilege.
A special admin user is part of the EMS server and is the equivalent to root in UNIX. By default, the admin user
has no password assigned when EMS is first installed. The admin user cannot be deleted. Permissions and
access control cannot be altered for the admin user. Administrator privileges are related to the configuration and
setup of the EMS server rather than access to the server from an application that requires access to the MOM
infrastructure.
The admin user can also grant application users (principals) access to a special group: $admin. Any user in this
group will be granted full admin user privileges. It is not generally recommended that clients use this feature, and
only admin should be assigned to group $admin.
In addition to the admin user and $admin group, normal users can be granted certain admin permissions.
There are 24 fine-grain administration permissions that can be assigned to individual users or groups.
Administration privileges include:
! View display information with regard to access control lists, destinations, users, groups, factories,
messages, routes and servers.
! Shutdown the server.
! Change Ability to change, delete or add: server, routes, factories, access control lists, and
connections.
! Delete destinations.
! Modify destinations.
! All administration permissions.
Administration permissions for users can be assigned globally for the entire server, or against specific fully
qualified or wildcard destinations. Again, careful consideration of destination names for both topics and queues will
simplify the number of directives that are required for customers to create destination-level administration
permissions.
There is a hierarchy of permissions available for the granting of administration permissions. The highest level is
the admin user and $admin group. Beneath this are the administrator groups or users that can have a very fine-
grain restriction on the administration capabilities within the entire server. Furthermore, administration permission
can be granted to specific destinations or groups of destinations referenced with wildcards.
34
2.6.3 Application Authorization
If authorization is enabled, and the application has authenticated itself to the EMS server, there is still destination-
level access control that is enabled by the administrator to restrict applications and their access to destinations.
If a destination is labeled secure then the user (principal) is restricted to the destination permissions assigned by
the administrator for that user to the destination. Again, wildcards and a well-thought-out naming scheme will
greatly simplify the creation of the user-level destination access control. The destination controls include:
! Receive (queue) Subscribe (topic) consume messages.
! Send (queue) Publish (topic) produce messages.
! Browse only for queues.
! Durable create durable topics subscription.
This will allow fine-grain control over destinations at an application user (principal) level.
Dynamic destinations will inherit the authorization and access control information of the parent destination. For
example, if only subscribe permission was granted to topic test.heinz.*, then the dynamic topic test.heinz.1
would also only have subscribe permission for the principal that was authenticated for the parent queue. Please
refer to Section 2.4 Temporary, Dynamic and Static Destinations for more details and benefits for dynamic
topics.
Authorization also applies to bridges. Messages cannot move from one destination to another via a bridge, unless
the target destination also has permissions as defined by the applications authenticated principal. For more
details on destination bridges please refer to Section 3.4.2 Destination Bridging.
2.6.4 EMS Routing Authentication and Authorization
Each server that is connected by a routed link must have a unique name associated with the server. This server
name is used to authenticate the server to another server for purposes of routing. Each server must have a
username entry that corresponds to the remote server name. A password is also required for the route to be
established.
After the route is established, administration for the route is simplified by the fact that the route partner acts as if it
was an application-level connection with regard to access control and permissions. The routed link makes use of
the route partners server name and password for authentication and authorization.
2.6.5 Use of SSL and Authentication within EMS
This topic has already partially been covered in Section 2.2.6 Message Encryption. Please refer to that section
for more details.
EMS supports two implementations of SSL. The default OpenSSL JSSE implementation is shipped with the
product. EMS also supports Entrust 6.1, but this requires the purchase of separate licenses from Entrust. It is also
important to note that if the EMS infrastructure is used in a .Net environment there is no support for SSL.
The SSL credentials are stored in X.509 certificates. The certificates can be referenced from storage as either
! DER or PEM encoded.
! PKCS#7
35
! PKCS#12
! Java KeyStore (only client certificates)
! Entrust Store (only client certificates)
A server can be set up to communicate over SSL and non-SSL from the same EMS daemon. This accomplished
by configuring the SSL and non-SSL communications over different socket connections; which is accomplished
through the configuration of the listen option in the EMS daemon configuration file. The default non-SSL
communications has a listen with a similar URL: tcp://7222. For SSL communications, another listen is added to
the configuration, but the URL is different, for example: ssl://7243.
The EMS daemon supports the configuration of several SSL-related parameters. There are two sets of
parameters for SSL that can be configured in the server. The first set is the SSL parameters associated with the
Fault-Tolerant communications and signaling between the EMS Daemon Fault-Tolerant server pair (see Section
3.3 Design for Fault Tolerance for more details on Fault Tolerance). The second set of SSL parameters is used
for client connections (which are also used for routing between EMS daemons, since the routed connection acts
as a remote client connection, except that the SSL parameters are part of the route configuration rather than
configured through the application).
The EMS Server (daemon) configurable parameters include:
! Diffie-Hellman Key Strength - When it is not possible to use export-grade cipher suites, D-H can be used
for negotiating symmetric key exchange (not for authentication). The strength of the key can be specified
in the EMS daemon configuration file.
! SSL Ciphers Authentication is accomplished using PKI, but this is a very processing-intensive way to
encrypt messages, therefore PKI is not used beyond authentication and negotiation of a key for use with
the less processing intensive symmetric key cipher. Once authentication has occurred, and a secure
symmetric key has been negotiated, several symmetric key algorithms are supported to actually perform
channel encryption. It is possible to specify the ciphers that are available for use with SSL and the order
of preference. Please refer to the TIBCO EMS User Guide for details on the supported symmetric
ciphers.
! SSL Renegotiation SSL does not use the same symmetric key or cipher for the entire lifetime of the
SSL connection. It must be changed on a regular basis. The renegotiation can be triggered either by tie
or the number of bytes streamed across the TCP connection. The EMS server exposes both of these as
tunable parameters. This allows administrators to set these SSL parameters to match the clients security
policies. By default, the time is 15 seconds and the stream is 64Kb.
! SSL Client Authentication All clients must authenticate the server, but it is optional to force the client to
authenticate to the EMS server (daemon). EMS supports enabling client authentication as part of the SSL
protocol negotiation. If this is not enforced, the EMS username password is used to authenticate the
client through the standard JMS ConnectionFactory.createConnection() method. If SSL client
authentication is enabled, the client ID can be extracted from the X.509 certificate (see Section 2.6.5Use
of SSL and Authentication within EMS for more details), but it is still necessary to pass the password as
part of the connection initiation.
! SSL Vendor As mentioned above EMS supports OpenSSL JSSE and Entrust 6.1 or higher.
! SSL Server Identity It is necessary to store the servers X.509 certificate and key on the host. The EMS
server is configured to point to the location of the files. These files are also encrypted. The server
36
decrypts the files using a password. This password can be presented at the time the EMS daemon is
started, or it can be saved in an obfuscated format in the EMS daemon configuration file.
! Server Issuer In many cases, if a common Certificate Authority (CA) is used to sign the server
(daemon) certificate, the signing Certificate Authority certificate is available in the
$JRE_HOME/lib/security/cacerts file. If a CA was used to sign the server certificate that is not part of
the standard Java distribution, it is possible to reference the required CA credential information through
the EMS server configuration file.
! Random Numbers The degree of randomness will affect the level of security afforded through SSL. A
simple random function does not generate truly random numbers in the cryptographic sense. Some
operating systems provide a special daemon that generates cryptographically acceptable random
numbers. This is the Entropy Gathering Daemon (egd). If egd is available, the EMS configuration can
be set up to point to this daemon and make use of stronger random numbers.
EMS also supports debugging and tracing of the SSL negotiations. This is very important when first trying to
configure and set up the EMS infrastructure. These tracing parameters are passed at startup on the command
line. Please refer to the TIBCO EMS Users Guide for more details.
Configuring the EMS server is only half the equation. The client applications also require setup to participate in the
SSL communications. The parameters are a subset of the parameters described above. There are three ways to
accomplish this:
! Using a JNDI call to Connection Factory object. This can be accomplished by using the EMS
administration interface or manual editing of the relevant factory file to specify the required SSL
parameters.
! Using a constructor for the relevant topic or queue TIBCO Connection Factory class.
! Using the TibjmsSSL helper class.
As always, for portability, the JNDI lookup and configuration is the recommended production mechanism for client-
side SSL configuration.
2.7 JNDI Lookup
The use of JNDI lookups for connection factory, topic reference and queue references is the recommended mechanism
for use in production environments (with the exception of dynamic destinations see Section 2.4 Temporary, Dynamic
and Static Destinations). When the EMS servers are set up and administered, the information is available as reference
data that is available to the applications through standard JNDI calls to the EMS servers. The EMS server supports
JNDI binds to retrieve data.
For JNDI to operate, it requires several system properties to be set into a hash table that references the vendors initial
context factory and the URL to connect to the JNDI-compliant data store. From this information the client application
can create a JNDI initial-context object that can be used to retrieve context factory, queue and topic references.
EMS supports secure JNDI lookups by using SSL. This is accomplished by setting up the SSL environment properties.
More details can also be found in the TIBCO EMS Users Guide.
EMS also supports fault-tolerant lookups when EMS is used as the fault-tolerant JNDI data store. Reference to the
server pair is as described for the JMS application connection (see Section 2.10 Client Fault Tolerance).
37
It is possible to store and retrieve reference objects from third-party JNDI-supported storage systems, including LDAP,
RMI or files. Unlike JNDI access via the EMS daemon, the fault-tolerant lookup or SSL connection is not available with
these third-party JNDI data stores. There are two methods of storing information in these data stores. Either a URL
reference to the EMS JNDI data store or a local reference can be stored in the third-party system. For more details,
please refer to the TIBCO EMS Application Integration Guide.
2.8 Working with Transactions
There are two types of transactions that are supported by JMS, session (some literature refers to this as message
transactions) and distributed transactions. There is also the concept of compensating transactions.
It is important to note that the transactional commit() method does not cause JMS consumers to send message
acknowledgements if CLIENT_ACKNOWLEDGEMENT mode is enabled for the session. It is still necessary to manually
acknowledge the messages, or they will build up in the EMS daemon.
Session transactions are provided as a mechanism to allow transactional bracketing around a group of messages. The
transaction can be from a sending session to the EMS daemon or from the EMS daemon to a receiving session.
For a sending session transaction, an application initializes a session to the connection indicating the session is to be
transactional (by setting the first session argument to true). From then on, all messages that are sent are considered
part of a single transaction until either a commit() or rollback() method is called on the session. If the group of messages
is committed, they are then available to be consumed from the EMS daemon. If they are rolled back (or the commit
fails), they are essentially deleted. After the commit or rollback, a new transaction is then automatically created. The
number of messages that are included in the transaction has no limit. The current transaction is closed and a new
transaction started with the commit or rollback methods being executed.
It is also possible to have receiver session transactions. In this case, a transacted consumer is created against a
session that as above was initialized as a transacted session. The receiver application consumes messages from the
EMS daemon. If there is a rollback method executed, then the messages are thrown back in the queue. At this point,
another receiving transaction starts and the messages will be redelivered with the redelivery flag set (see Section
2.2.1.10 JMSRedelivered Header Field for details).
It is also possible to bracket a message receive and a message send in a single transaction. This is accomplished by
initializing a producer and consumer against the same transacted session, and then consuming a message, then send
a message and then committing the transaction. This type of transaction is target at synchronous request/reply
interaction, where the receipt of one message and the sending of the reply are part of the same transaction. It is not
recommended for asynchronous request/reply.
EMS also supports bridging as part of the sending transaction. When messages that are part of the transaction are also
bridged, then, if the commit is successful to the EMS daemon, then the messages are moved to the bridge locations. If
the commit fails, or there is a rollback, the messages do not move to the bridged locations. In addition, if the movement
of messages to the bridge locations fails, the commit is considered unsuccessful, and the transaction is rolled back.
(See Section 3.4.2 Destination Bridging for more details on destination bridges.)
Session transactions are also significant during EMS daemon failover. If a new transaction has started (i.e. at least one
message of a transaction has been delivered to the EMS daemon), and the server fails over before the commit, the
commit will fail and the transaction will be rolled back. The session also throws a specific exception in this scenario, the
javax.jms.TransactionRolledbackException (normally a failed commit would throw a JMSException exception). It is
recommended that applications trap this special exception and the client application should attempt to resend the
38
messages to the EMS daemon. All messages that were sent to the server, that were then rolled back because of the
failover will be flagged as resent when they are sent again by the client.
EMS also supports distributed transactions, which are sometimes referred to as two-phase commits. This usually
involves an external transaction monitor. Distributed transactions are more robust than session transactions. A session
transaction only has a commit() and a rollback() method. Distributed transactions through EMS support the full XA
interface and associated objects and methods. An example may require the co-ordination of a JMS message being sent
and a database write. If one fails they both must roll back. EMS supports this through JTA (Java Transaction API) and a
standard XA-compliant transaction manager. EMS supports the standard JTA XA API objects:
! XAConnection
! XASession
! XAConnectionFactory
! XAQueueConnection
! XAQueueConnectionFactory
! XAQueueSession
! XATopicConnection
! XATopicConnectionFactory
! XATopicSession
Each of these objects operates like their non-XA equivalent.
When monitoring the EMS server, the XA transactions are flagged in the session reports. An XA factory can also be set
up in the EMS daemon for reference for the required connection factory through a JNDI lookup.
It is important to note that the session defines whether the application will employ transactional semantics. Therefore,
separate sessions should be created for transactional consumers and producers.
2.9 Synchronous and Asynchronous Interaction
Traditionally, references to synchronous communications and RPC communications were used interchangeably. In a
typical peer-to-peer architecture, this was fine. With JMS there needs to be a distinction between the communications
level and the application level.
From an infrastructure perspective, JMS is an asynchronous communications model. The producer and the consumer
no longer directly communicate. Messages are sent in a store-and-forward architecture. This simplifies the integration
model from the old RPC mechanism where there was a requirement for each application to have direct communications
with each peer. With JMS, the producers send messages to the infrastructure with no knowledge of the location or the
availability of the consumer(s). Therefore, from a communications perspective, JMS is an asynchronous messaging
technology.
Regardless of the messaging layer, it is still possible to implement a synchronous request/reply processing model with a
JMS producer. A producer can send a message and block and wait for a reply. Although the messaging layer is
asynchronous, the application can still be synchronous. For example with topics, this request-reply interaction can be
implemented with the TopicSubscriber.receive() method (there is also the equivalent for queues), where the reply
message is dispatched manually, and the method blocks until a reply is received. It is also possible to use the JMS
TopicRequestor helper class. To fully implement the request-reply model, JMS also provides the JMSReplyTo header
39
(see Section 2.2.1.7 JMSReplyTo Header Field) and temporary destinations (see Section 2.4 Temporary, Dynamic
and Static Destinations).
It is also possible to use this same processing model for non-request/reply consumer. A message consumer is created
against the session, and messages are manually dispatched, but no replay is sent to the producer. The code would be
similar to:
Destination destination = session.createTopic(theTopic)
MessageConsumer msgConsumer = session.createConsumer(destination);
connection.start();
while(true)
{
Message msg = msgConsumer.receive();
System.out.println(Received message: + msg);
}
JMS also supports an asynchronous processing model. Messages can be delivered to the destinations, and then
automatically dispatched for processing through the onMessage() callback method. This type of processing is a push
model of publish-subscribe. Rather than manually dispatching the messages with the TopicSubscriber.receive()
method or a MessageConsumer.receive(), a message consumer is registered against the JMS session for a specific
destination, and a listener is created against the message consumer that dispatches messages to the onMessage()
callback method. The listener is a non-daemon thread, so the callback will run forever until the application is stopped
(i.e. there is no need to have main() hold some kind of loop or thread join() to ensure the application does not end once
the asynchronous messaging is set up and the main method completes what it needs to accomplish).
An example of asynchronous dispatch of messages in the consumer would be as follows:
Destination destination = session.createTopic(theTopic)
MessageConsumer msgConsumer = session.createConsumer(destination);
MsgConsumer.setMessageListener(this);
connection.start();
Of course, the applications outer public class would have to implement the MessageListener interface and an
onMessage() method. Of course it is possible to implement the onMessage() method in another class, and then pass
the instantiated object to the setMessageListener() method. Notice that the while-loop is no longer required. The
messages are now dispatched through the non-daemon dispatcher thread. This dispatcher can be changed to a
daemon thread, but this will require some control over the application to ensure it does not reach the send of the
main() method, or the application will end, and the non-daemon dispatcher will also then exit. See Section 2.10.3
Tibjms Object for more details on changing to a non-daemon dispatcher.
It is important to note that until the onMessage() method returns, there is no further dispatching of messages for
processing (if a single dispatcher is used). Therefore, timely return from the callback will improve processing
performance. It is also possible to have onMessage() fork its own thread. This will cause the callback to immediately
return. However, if auto-acknowledge is set, then the EMS daemon will remove the message immediately, even if the
callback has not completed (or even failed) to completely process the message. As a result, it is recommended to
manually acknowledge messages if threaded callbacks are used as part of the application design.
It is recommended to create all the asynchronous dispatched before the connection thread is started. No dispatching
from the destinations occurs until the connection against which all the sessions have been established is started.
40
The MessageConsumer.SetMessagelistener() method creates its own dispatching thread, and the callback runs in this
thread. It is therefore, possible to create more than one asynchronous message dispatcher thread against the same
destination. There is little benefit in using this for topic destinations since the multiple threads will simply process the
same message multiple times, but there will be an application processing throughput performance improvement if the
destination is a non-exclusive queue. With non-excusive queues, any one consumer only processes each message
once, but it is possible to create more than one active consumer against the same queue destination. Therefore,
multiple listener dispatching threads will provide parallel processing of messages in a fashion similar to having multiple
separate applications listening on the same non-exclusive queue (see Section 2.3.1.2 Scaling and Performance Tuning
of JMS Queues with EMS for more details).
2.10 Client Fault Tolerance
The EMS servers can be set up as a fault tolerant group (see Section 3.3 Design for Fault Tolerance for more details).
In the event of a failure of the EMS daemon, another EMS daemon can be set up to automatically read the state
metadata and the persistent message data from the original EMS daemon and take over on its behalf. Unfortunately,
the connections from the client to the EMS daemon are state-oriented TCP connections. Therefore, it would be
necessary for the client to disconnect and then reconnect to the new daemon. With EMS, this is not the case; the API
takes care of this on behalf of the client. The client is not aware that there has been a failover -- except in the scenario
where a transaction was started but was not committed before the failover (see the previous section for more details).
It is important to note that the FT daemon processes that constitute the FT pair must share the same process name.
Although the clients are TCP/IP state-oriented connections, clients can transparently support EMS daemon fault-
tolerant (FT) failover. This is accomplished by specifying a special URL when establishing the connection. The URL
essentially points to the two separate EMS daemon FT server pair. An example of the URL is as follows:
tcp://server01:7777,tcp://server02:7776
The URL basically points to the two servers, and their corresponding connection port for creation of the TCP connection
between the server and the client application. When the client application starts, it attempts to connect to servers in the
order specified in the URL. The server binds to the first successful connection. It will stay connected until there is a
failure. At this point, it again attempts to create a connection in the order of the URL. Connection attempts are not
restricted to a single retry. It is possible to specify the number of retry attempts and the delay between the retry
attempts. By default, the client will stay active for approximately 10 seconds trying to reconnect.
2.10.1 Client Fault Tolerance and Delay in Failover
If 10 seconds is not enough time for the fault-tolerant fail over, the connection retries and delay between retries
can be modified to suit the time required for reconnection. This is very important if HA hardware clusters are used,
where the failover can possibly stretch to minutes rather than seconds. Reconnection delay is also important when
there are many connections to the same EMS daemon, and it may take some time for them all to reconnect to the
daemon after a failure.
The delay between retries and the number of retry attempts are part of the connection factory definition. The
details can be defined in the JNDI data store, or through the manual creation of the connection factory object.
There are three ways to specify or modify the retry and retry delay parameters for JNDI reference to the
connection factory:
! The first mechanism is to make use of the TIBCO EMS Admin API and the ConnectionFactoryInfo class.
This class allows the application to create or alter ConnectionFactory object properties in the JNDI store
(i.e. the EMS server factory information stored on disk). For client fault tolerance, the
41
setReconnectAttemptCount() and setReconnectAttemptDelay() methods are the two relevant methods
that must be called to adjust the time allowed between the failover. While this is a feasible mechanism to
adjust the client reconnections, it makes use of the proprietary TIBCO Java API, and, therefore, the code
would not be portable, although it would be acceptable for use as a custom administration application.
! Fortunately, the required parameters are also available through editing the EMS server-referenced
factory file (the default is factories.conf) that is referenced by the JNDI call to the EMS server to
retrieve the connection factory object. The connection factory reference in the EMS daemon factory
configuration file can be configured to include the reconnect_attempt_count and the
reconnect_attempt_delay properties that will be set automatically if the connection is established based
on the JNDI called connection factory reference. After the files are edited, it is necessary to restart the
EMS daemon to read the new parameters. This is the preferred method to adjust the client reconnection
parameters for connection to fault-tolerant EMS daemons if the changes are not to be used until the next
restart of the daemon.
! Finally, it is possible to modify the factory reconnection delay and attempt count values through the CLI
(Command Line Interface) administration utility. The same parameters as above are modified, but the
configuration file and the running daemon are both updated simultaneous. Therefore, the changes are
immediately available to the next client connection that is established to the daemon.
It is important to note, that these changes do not affect connections that are already established to the server. In
addition, the changes must be made to all EMS daemons and their respective configuration files if they are acting
as JNDI stores for the JMS connection factory information.
It is also possible to modify the client application to allow changes in the FT process with regards to reconnection
delay and attempt count. If the application programmatically creates the connection factory without making use of
JNDI, it may be necessary to modify the FT parameters in the application. This may require the use of non-JMS-
compliant code since creation of the connection factory is vendor-specific. As mentioned several times before, the
use of JNDI calls is the recommended mechanism since it allows central administrator configuration on behalf of
all clients and eliminates the need for any vendor specific-code in the JMS application.
There are three mechanisms available to modify the FT parameters when manually creating the connection
factory (as opposed to calling the object from JNDI):
! Modify the Tibjms object before creating the connection factory object,
! Setting a Java system property, either through the java command line, or directly in the application,
! Creating a Java Map that contains the FT properties, and passing that Map as an argument to the
tibjmsConnectionFactory constructor.
To provide the new client non-default FT parameters is simply a matter of modifying the Tibjms object before the
connection factory is created. The following is an example of the required code:
String reconnect(12,5000);
Tibjms.setReconnectAttempts(reconnect);
ConnectionFactory factory = new com.tibco.tibjms.TibjmsConnectionFactory(FTserverURL);
42
Note that the attempt count (12) and the delay (5000 ms) are a single string. This is also different from the
requirements for Load Balancing, where the metric parameter is passed through a Map as part of the
TibjmsConnectionFactory constructor (see the EMS LB sample code included with EMS for more details).
It is also possible to set these values for reconnection through Java System Properties. In the code, this is
accomplished using:
System.setProperty(Tibjms.PROP_RECONNECT_ATTEMPTS,12,5000)
It is also possible to provide the same Java System Properties from the Java command-line. This is very important
if you do not have access to the source code, such as for Business Works. The command line argument is also a
clean mechanism for providing the required parameters without modifying the source code to include TIBCO-
specific connection factory methods (recall the connection factory is always vendor specific with JMS). While it
makes the code cleaner, the startup does require the Java system property parameters to be included. The
command line argument is a bit different since the first field in the method above is an EMS constant field
referencing a string. The command line argument in Java would be:
java Dtibco.jms.reconnect.attempts=12,5000 java_program
The third option is to build the properties in a Java Map and then pass the Map as part of the
tibjmsConnectionFactory constructor. This is only available with EMS 4.1 and above. A simple code sample
would be:
HashMap mprops = newHashMap();
mprops.put(Tibjms.FACTORY_RECONNECT_ATTEMPT_COUNT, new Integer(12));
mprops.put(Tibjms.FACTORY_RECONNECT_ATTEMPT_DELAY, new Integer(5000));
ConnectionFactory factory = new com.tibco.tibjms.TibjmsConnectionFactory(serverURL,null,mprops);
This pattern of creating a connection factory is similar to the mechanism used for JNDI connections, and Load
Balanced connections (please refer to Section 3.3.2 Clustering for more details).
The servers are also configured to wait a certain period before the client reference is removed from the backup FT
server. The default is 60 seconds. This is the servers ft_reconnect_timeout. It also may need to be increased if
the FT EMS daemon pair is in an active-active configuration and the failover time may be greater than 60
seconds. If this server parameter is not increased, but the client failover tolerance is increased, the server may still
remove the client reference from the server metadata while the client is still transparently trying to reconnect.
It is important to note that the client can reconnect to either the original EMS daemon or the failover daemon. The
client will continue to try and connect, even if there is no primary or backup daemon available during the
reconnection window. This is important when HA (High Availability) configurations are used, and the hardware is
failing over. In this case there is no daemon available until the secondary HA host becomes available and starts
the backup EMS daemon.
2.10.2 Client Fault-Tolerant State Transition Trapping
If the client reconnection should fail, JMS provides an ExceptionListener interface that allows the client
application to trap the exception that is thrown after client fails to re-establish connection. If the client application is
written to implement the ExceptionListener interface, then it is possible to provide an onException callback that
is executed when the connection is lost. Adding an onException callback method to the client application and
43
using the JMS connection class method setExceptionListener registers the exception listener to execute the
callback method. Now, when the client connection fails to reconnect in the allotted time, the developer has the
opportunity to provide control over what is to happen next through the callback method. An option may be to
automatically try and create a fresh connection.
An example of using the exception listener can be found in the tibjmsMsgConsumer.java example program that
is included with the EMS installation.
The same asynchronous exception message from the JMS connection can be used to monitor the event of client
failover from one FT EMS daemon to its partner. To enable this requires the setting of a Java system property.
This is available within the application through the line (which should be placed at he beginning of main()):
System.setProperty(tibco.tibjms.ft.switch.exception,true);
It can also be set, as with all Java system properties, from the Java command line, for example:
java Dtibco.tibjms.ft.switch.exception=true tibjmsMsgConsumer server tcp://localhost:7222,tcp://localhost:7224
Of course, for the monitoring of FT failover events, the exception listener must also be enabled, and the callback
added to process the failover event message. It is also important to note that the Java application must implement
ExceptionListener.
As mentioned in the previous section, the use of command-line option ensures the Java Code contains no TIBCO-
specific implementation details.
2.10.3 Tibjms Object
The Tibjms class is a very important object in the EMS client implementation. It contains and defines many of the
constants and System Properties used by the EMS client applications. The Tibjms class is part of the
com.tibco.tibjms package. This package provides the classes for SSL setup, administration with external JNDI,
as well as proprietary constants such as vendor-specific Message properties and others. Essentially, Tibjms
captures most of the definitions used for the TIBCO specific implementation of the JMS client interaction to the
EMS infrastructure. These interactions, such as connection factory implementation are not defined by the JMS
specification.
There are many mechanisms available to modify and configure this object. It is also important to note that there
are some additions to this object with newer versions of EMS. The ways to modify or interrogate this object
include:
! Constants are set based on vendor specific message properties (see Section 2.2.2.1 Provider-Specific
Properties for more details),
! Through the explicit use of accessor or mutator methods (see Section 2.10.1 Client Fault Tolerance and
Delay in Failover for an example),
! The setting of Java System Properties, either from the Java command line or through programmatic
definitions (see Section 2.10.1 Client Fault Tolerance and Delay in Failover for an example).
! Modifying the Tibjms object constants directly.
Examples of the use of the Tibjms class have been covered in the previous section that discusses client fault
tolerance.
44
It is important to note, that if you set properties in a Java Map, and pass them to the connection factory
constructor, the constants in the Tibjms object may not necessarily be updated. An example of this can be found
in the previous section.
The details of this class can be found in the HTML JavaDocs that are included with EMS installation. It is
important to note that in many cases the get methods in this class will return a null or 0 if the default value is
used. This does not mean that the value is not set, merely that the internal defaults are used. The default values
are found in the JavaDoc.
This object provides a great deal of control of the internal implementation of the client TIBCO-specific
implementation of the JMS specification. This is not a TIBCO extension to JMS, merely the vendor-specific
implementation as allowed as part of the JMS specification.
Some of the major capabilities afforded through this class include:
! Referencing Load-balanced-mode metric parameter
! Referencing client connection and reconnection attempt count and delay and actual counts
! Referencing TIBCO-specific JMS message properties
! Referencing the TIBCO extensions for delivery mode quality of service
! Referencing SSL setup and parameters
! Referencing the dispatcher thread status (change from non-daemon to daemon thread)
! Referencing Message-specific properties and data
! Referencing socket send-and-receive buffer sizes (not available for all operating systems)
! Reference connection error callback capability
It is highly recommended that developer and architects familiarize themselves with the class and its capabilities
and interaction, since it contains the TIBCO-specific JMS implementation capability reference as allowed as part
of the JMS specification.
2.11 Pre-packaged TIBCO EMS Applications
2.11.1 Using EMS in BW
For more details, please refer to Section Deploying EMS with BW 5.. Also, please refer to the JMS Palette
details found in the TIBCO Business Works documentation.
2.11.2 Using EMS in Adapters
TIBCO provides many COTS (Common Off-The-Shelf) adapters. Most of these adapters support either JMS or
Rendezvous messaging capabilities. It is simply a matter of choosing and configuring the desired messaging
transport. This configuration is accomplished through TIBCO Administrator, which manipulates and stores the
adapter metadata configuration files.
Custom adapters can also be created using the TIBCO Adapter SDK. The adapter SDK defines AEXML as the
wire format for JMS messages. This is essentially a JMS Text Message that contains an XML payload. The
45
payload XML also contains the AE control information as XML tags (see Section 2.2.4 Message Wire Formats
for more details).
The use of Adapter SDK to create adapters does not make use of the JMS API, but the SDK also provides
libraries for tracing, debugging Hawk, metadata management, message verification and format, etc, that are not
available as part of the JMS API. Therefore, Adapter SDK makes use of the EMS infrastructure, but not the JMS
API.
It is also important to know that the message transport and transport configuration is created outside of the SDK
adapter application (it does have the facility to create everything in the application, but this is not the
recommended use in the creation of adapters). All the transport information is referenced from metadata that is
read at application startup. Therefore, any applications written with the Adapter SDK can change its transport and
transport quality-of-service simply by changing the metadata without recompiling the application.
2.11.3 Using Rendezvous over EMS and Rendezvous/EMS Bridging
There are two ways to interact with Rendezvous from EMS. The first mechanism allows Rendezvous applications
to communicate directly with the EMS infrastructure. This is accomplished by using a special RV transport called
TibrvJMSTransport that is found in the tibrvjms.jar. Therefore, in addition to the other RV jar files. This must be
included in the Rendezvous application class path.
It is important to note that only reliable mode quality of service is supported with the TibvJMSTransport. This
transport is also only available for use with topics and not queues.
The second alternative for communications using Rendezvous is through the EMS bridging function. Bridging is
accomplished directly through the EMS daemon, and not through a standalone client application. EMS supports
bridging between not only queues and topics (see Section 3.4.2 Destination Bridging for more details) but
between EMS and Rendezvous and/or Smart Sockets transport. Unlike the use of the JMS transport directly in the
Rendezvous application, the bridge supports all Rendezvous qualities of service and messaging paradigms. All
communication between the EMS applications and Rendezvous is controlled completely though simple
configurations and set up of the EMS daemon. Neither the JMS nor the Rendezvous applications are aware that
this bridging function is occurring.
For the bridging to occur with the proper EMS destination (queue or topic), the Rendezvous subject name and
JMS destination must match. If there are two destinations with the same name, then only one destination is
allowed to have bridging enabled.
Bridging is unidirectional. The bridge can be set up to send to, or receive from Rendezvous. This can occur
simultaneously to the same EMS destination, but must be configured separately. If the Rendezvous application is
written in Java, then there should be little issue with any of the JMS message types (see Section 2.2.3 Message
Payload Types for more details and details about limitations when using other language bindings).
Please refer to the TIBCO EMS Users Guide for more details about the configuration of destinations to support
bridging between JMS and Rendezvous. In addition, please refer to 2.2.2.1 Provider-Specific Properties for more
details about JMS properties and Rendezvous message and payload mapping.
2.11.4 Using Hawk over EMS
Starting with Hawk Version 4.5, there is now support for Hawk over JMS. There is still a requirement for a
Rendezvous Daemon on each host, but this is used strictly for inter-process communications between the Hawk
agent and the Hawk instrumented applications. This communications is strictly local, and no Rendezvous
messages are found on the network.
46
With older implementations of Hawk, it is possible to distribute the RV Hawk message through the EMS
infrastructure using the JMS/RV bridging capabilities (see previous section).
Communications between the Hawk Console and the Hawk Agents are now supported over the EMS
infrastructure.
For more details, please refer to the Hawk documentation.
2.12 Integration with EJB App Servers
There are four approaches to integrating with the EJB vendors. The first approach is to make use of the TIBCO EJB
adapter. This is not necessary if the EJB container supports JMS natively, and, therefore, does not require the use of
the TIBCO adapter.
The second approach is to make use of a protocol-level adapter. This is discussed in Section 3.8 Interacting with Other
JMS Providers.
A third approach is to make use of integration tools such as TIBCO Business Works. Interaction with the beans is
available through BW where there are standard pallets for the EJB Home, Remote and Connection objects.
The final approach is to directly make use of the EMS JMS implementation within the EJB container. This would result
in the most seamless solution for JMS communications in and out of the EJB environment into a standard
implementation of a JMS messaging backbone based on EMS.
It is simple to add EMS support to the EJB environment. The TIBCO EMS Application Integration Guide describes the
setup and installation to use TIBCO JMS implementation for multiple EJB vendors. A summary of the required steps, for
WebLogics for example, is as follows:
! Add the EMS jar files to a location referenced by the WebLogic class path.
! Create the appropriate foreign connection factory and destination settings in WebLogic to point to
EMS for the JNDI lookups for connection factories and destinations (recall that these are vendor-
specific implementations within the JMS specification).
! Create the required destinations within the EMS servers.
! Modify the weblogic-ejb-jar.xml file for the MDB to use the appropriate connection factory and
destinations.
! Modify the client programs to use the EMS JNDI lookups for the administered objects.
More details on this setup are available in the TIBCO EMS Application Integration Guide.
47
3 EMS Server Best Practices
Setup and configuration of the EMS daemons is a very misunderstood topic. This chapter helps EMS practitioners such
as system or integration architects and infrastructure staffs like network and storage engineers to understand various
issues and implications they can encounter when planning, designing, deploying, and managing EMS. This section has
many cross-references to other sections in the document.
3.1 System Requirement and Planning
This section only briefly outlines some of the planning requirements, and is not meant to act as a replacement to the
details outline in the relevant EMS documentation.
3.1.1 Network Architecture
EMS is supported over any network that supports TCP/IP. It is important to note that as a messaging
infrastructure, the performance of the EMS daemons will be affected by the performance of the network. If the
network is already heavily used or suffering from errors, the EMS infrastructure will also suffer. However, the lack
of messaging performance is only a symptom of the problem that in fact may be a network issue.
The JMS specification defines a store-and-forward model for message delivery. As a result, the message will be
on the wire twice, once to the EMS daemon, and again from the daemon to the consumer. Therefore, message
capacity planning needs to be at least twice the rate of messages expected to be delivered to the consumer. It is
also important to note, that with CSMA/CD networks like Ethernet, that 25% continuous bandwidth saturation is
the effective limit for efficient communications. More bits on the network do not always translate to more data on
the network, and the network delay will begin to rapidly increase, reducing individual throughput rates.
In many cases, the same message may be required in more than one destination. This should not be done from
the client side where the same message is sent more than once. This will unnecessarily increase message traffic.
For this scenario, message bridging (possibly with selectors) should be used to reduce the network traffic and the
processing overhead of the message producer (see Section 3.4.2 Destination Bridging for more details on
message bridging).
Communications between the clients and the daemon is TCP/IP. The client can be located anywhere in a routed
network. For performance reasons, it may be required to place another EMS daemon on the different subnets and
use routing to move the messages across the router between the EMS daemons. In this way, the message only
crosses the router once, regardless of the number of consumers and producers for the routed destinations.
Without using this technique, the same message would cross the router for each consumer and producer across
the subnet barrier. This is especially important when moving messages across slower wide-area links that have
more restrictions on bandwidth.
JMS specification also assumes a very reliable delivery of messages. This reliability requirement introduces a
large amount of protocol overhead. Guaranteed delivery is not always necessary as part of the messaging model.
Therefore, EMS supports reducing the protocol overhead to reduce the network traffic and increase the
performance of messages through the EMS daemons. Please refer to Section 2.3.1.2 Scaling and Performance
Tuning of JMS Queues with EMS for more details on reducing protocol overhead (note, the same details are also
relevant to topics).
Selector functions can also be employed by clients to reduce network traffic. With selectors, the client can indicate
to the EMS daemon that only messages that actually match the selection criteria should be sent to the client for
processing. Unfortunately, client selectors will affect the deterministic nature of the architecture, and, therefore,
48
may make it more brittle. Please see Section 2.2.2.4 Message Selectors for more details. Selector functions are
also available for use with EMS routing and bridging functions, and, as a result, may improve network
performance and utilization, without the issue associated with client application selectors.
3.1.2 Storage Architecture
3.1.2.1 Storage Hardware
EMS requires storage for persistent messages, state metadata and configuration data. The limiting factor for
performance, especially for persistent messages, is the disk drive configuration. Issue related to the disk
storage and recommendations and options are discussed in the following sections of this document:
! 2.2.1.2 JMSDeliveryMode Header FieldJMSDeliveryMode Header Field
! 2.3.1.1 Queue Message Flow Control
! 2.3.1.2 Scaling and Performance Tuning of JMS Queues with EMS
! 2.3.2.2 Topic Flow Control
! 2.3.2.3 Durable Topics
! 2.4 Temporary, Dynamic and Static Destinations
! 2.10 Client Fault Tolerance
! 3.1.3.2 I/O Subsystems
! 3.3 Design for Fault Tolerance
! 3.3.4 Shared Storage System
3.1.2.2 File Systems
Please refer to the previous section for references to EMS and file systems.
3.1.3 Physical Server Architecture
3.1.3.1 CPU and Memory
It has already been discussed that there are two mechanisms that are used for storing the messages from
message producers. The messages can be stored persistently to disk, or within memory. The decision for
which to use is based on the requirement to preserve messages for recovery due to a failure of an EMS
server. While fault-tolerance will ensure that another server will allow processing if the primary server has had
a catastrophic failure, the messages must be persisted to disk is they need to be recovered.
However, not all messages require persistence. Persistent messages also have slower throughput and put
more strain on the servers. Therefore, persistence should only be used when required.
Flow control is also used to ensure that message storage does not expand past the capabilities of the storage
facilities (see Section 2.3.1.1 Queue Message Flow Control and Section 2.3.2.2 Topic Flow Control for a
more detailed discussion). However, non-persistent messages will also use the limited memory resources.
While flow control will restrict the use of memory for message storage (memory is still used when storing
persistent messages, but to a far lesser degree than with non-persistent messages), memory usually has
49
much smaller capacity than disk capacity, which would greatly restrict the capability of using memory for non-
persistent storage. Memory usage with persistent messages is also relatively non-deterministic, especially if
other applications are running on the same hosts as the EMS server (something that is not recommended, if
possible).
To help alleviate this issue for non-persistent messages (only memory is used to hold messages), EMS
supports several options that can be tuned in the EMS daemon configuration file, including:
! Memory Swapping EMS can ensure that the physical memory of the EMS server is not overrun by
limiting the maximum memory used for messages by setting the max_msg_memory parameter and
enabling the msg_swapping parameter. When memory is exceeded, the EMS daemon starts
swapping message memory to disk. Each swapped message uses some amount of real memory. If
the maximum memory setting was low and there was a high rate of messages, it would be possible to
have all memory used and all messages swapped to disk, preventing new messages to be delivered.
This will result in an error when trying to write to the daemon. This should not occur if the parameters
are set to a reasonable level. This swapping provides much higher performance then relying on
operating system swapping.
! Pre-allocated Reserve Memory This parameter allocates a block of memory to be used by
consumers in case of the situation where storage resources have been exhausted. Allocating this
memory for consumers in this extreme processing state allows consumers to continue operations,
thereby freeing storage resources and allowing clients to unblock and continue sending messages.
This parameter is reserve_memory.
! Memory Message Pools - As with disk, it is more efficient to pre-allocate memory rather than
constantly requesting and releasing memory. This is accomplished in two ways (note the size is the
number of internal messages structures and not bytes):
o Expandable Memory Pool - The server can be configured with a msg_pool_block_size
parameter. This instructs the EMS daemon to pre-allocate an expandable memory pool, and
then allocate additional pools of the same size when required (or until memory is
exhausted). The values range from 32 to 64K in size. If neither this prameter nor the next
parameter is set, the default EMS behavior is a 128 msg_pool_block_size.
o Pre-Allocated Fixed Memory Pool - The server can be configured with a pool_pool_size.
This allocates a fixed pool, and after the pool is full, the malloc system call is called to
expand memory use. The fixed pool is available in the range from 16K to 1024M. If this
parameter and msg_pool_block_size are both configured, this feature is ignored.
If flow control is not enabled, message producers will receive an error when they attempt to write a non-
persistent message and all memory and swap resources are exhausted. The use of swap allows the
expansion of memory capabilities for non-persistent messages, without, necessarily, the requirement of adding
expensive memory. It is important to note that when swapping does occur, it will begin to affect the
performance of the servers and the throughput of non-persistent messages. Fortunately, the thresholds and
use of swap are parameters that can be monitored.
The EMS daemon is multi threaded; therefore, it will receive some benefit from running on a multi-CPU host. It
should be noted that the daemon process is heavily I/O bound, and, therefore, will not necessarily be
computationally intensive. Therefore, the daemon process will potentially use a great deal of system mode
CPU time and can potentially generate a high level of context switches. With high I/O requirements, the server
may start to run into operating system limitations before it runs out of CPU or memory. As a result, large multi-
50
CPU boxes may have little performance increase for EMS. To solve I/O problems requires horizontal scaling to
multiple hosts, and this is part of the EMS infrastructure architecture.
3.1.3.2 I/O Subsystems
EMS and the JMS messaging model put a very high demand on both the network and the disk I/O
subsystems. Therefore, the performance of these subsystems will generally be the bottlenecks in performance
threshold of the EMS daemon.
From a network perspective, altering a few tunable parameters will aid in performance, such as increasing the
send-and-receive window buffers for TCP. When generating messages, the MAC layer will also possibly result
in segmentation and reassembly (SAR) of the JMS messages (actually JMS message in the TCP/IP
message). This is a heavy operating system burden and will affect throughput and performance. Limiting the
messages to about 1200 bytes will ensure no SAR. It is recommended to check the network when generating
the messages to ensure that SAR is not occurring at the MAC level. In some cases, there is no control on
message sizes.
Larger messages will also affect the performance when using persistent messages since it will take more time
to write to the disk. Message compress will help in this case and also help with flow control issues (see Section
2.2.5 Message Compression for more details on compression.
The faster the disk, the better the performance when using persistent messages. RAID arrays will not only
ensure better performance but will also provide disk reliability. Journaling file systems will also increase
performance and reliability.
EMS daemon can be configured to performance writes as either buffered or synchronously (controlled through
the FAILSAFE parameter. This will also have issues with performance since synchronous writes will provide
better reliability, but at the expense of performance. More details about disk issues and disk issues related to
fault tolerance can be found in Section 3.3 Design for Fault Tolerance.
The EMS server also supports three additional parameters for controlling the storage of persistent messages:
! store_minimium for performance reasons, a certain minimum amount of disk is preallocated for
storage.
! store_crc check sum data is stored with the data. This parameter controls whether the check sum is
checked when the data is read from the disk.
! store_truncated if enabled, the files are periodically truncated if the storage is no longer in use.
The adjustment of these parameters will affect performance. It is recommended to set preallocated storage.
Checking CRC may affect reliability if turned off, but at a statistically very low probability. Turing off CRC check
will increase performance. Disabling store_truncated will result in the file growing and never giving up the
space until the EMS daemon is restarted. If it is not necessary to automatically give back the space, then
performance will be improved.
3.2 Basic EMS Daemon (Server) Element
The simplest form of deployment is a single host with a single EMS processing element. The architecture would be as
follows:
51
It is not recommended to use this configuration for purposes other than development. It provides no availability features,
but will provide the basic messaging services. If the BSE is hosted on hardware that provides High Availability
capabilities, then it is perfectly feasible to use a BSE as a production infrastructure element.
The Basic Server Element (BSE) consists of the Server Element (EMS server process) and disk storage.
The Server Element represents:
! The EMS server process
! JNDI data store
! Queue Destinations
! Topic Destinations
The Disk represents storage for:
! Configuration data
! Metadata
! Persistent and Durable data store
The Consumer and Producer are applications that use the Basic Server Element
52
It is feasible to have more than one BSE on a single host. It is important to note that this will reduce the deterministic
nature of the processing load for the host and this will create a brittle architecture.
3.3 Design for Fault Tolerance
The EMS server is a critical component of the JMS infrastructure; therefore, its availability is required to ensure
industrial-strength processing can be accomplished at the messaging layer. One of the features of EMS is its ability to
support a fault-tolerant pair of EMS server. The pair acts as an active-passive fault-tolerant pair. It is also possible to
setup EMS servers to operate correctly in hardware High Availability (HA) clusters. While this section references the
server side of EMS availability, there are also client implications, more details can be found in 2.10 Client Fault
Tolerance.
Active-passive is not the only option for fault tolerance. EMS servers can also exist in hardware HA environments where
only one instance of the EMS fault-tolerant pair is actually running at any one time. Generally, with hardware HA, the
primary server is the only one running the EMS software. When it fails over to the secondary server, it will have visibility
to the original servers files (usually mounts the partitions as part of the failover), and automatically start another EMS
server (the second EMS server for the fault-tolerant pair) pointing to those files. Most hardware HA cluster servers take
over the IP and MAC address from the original, so it appears as though the original server just stopped and restarted
(although this is not required with EMS, and simplifies the HA setup and installation). Client connections can still appear
to persist even in this environment where the secondary HA host changes addresses (see Section 2.10 Client Fault
Tolerance for more details). It is important to note, that there is no requirement for distributed file locking on the shared
disk media for basic HA configurations where only one member of the fault-tolerant EMS daemon pair is running at any
one time.
In hardware HA clusters, the cluster software also monitors the availability of critical processes, such as the EMS
daemon. However, the software does not have much knowledge about the process beyond the fact is it running or not.
If the process dies, cluster software is supposed to try and restart the application. If this HA capability is not available for
a particular HA cluster vendor, it is also possible to have an active-passive pair configured on each HA server, but the
pair on the secondary HA host will still be down until failover. The secondary HA server (backup host) will have a similar
configuration, but both EMS daemons processes will be stopped until hardware failover occurs. Therefore, if one
process dies, the standby process immediately takes over. File locking on the shared media is still an issue for this
configuration if a SAN is used, or other shared media that do not natively support distributed file locks (this capability is
available for SAN, but is usually a third-party option).
For the EMS daemons to operate correctly as an active-passive pair in fault-tolerant mode (i.e. a member of the fault-
tolerant pair is running on each of the HA hosts), there is a requirement to have access to shared disk media. This
accomplished through SAN, NAS, file server, dual-ported SCSI RAID array, or whatever the customer decides as part
of their architectural requirement. It is important to note that a distributed file lock is required as well. Part of the active-
passive setup requires the passive server to see a lock on the metadata and message persistence files. It is also
important to note that file systems like NFS do not provide this capability.
The shared disks must contain the meta-data and the data store for the synchronous and asynchronous disk writes
(controlled by the fail-safe parameter in the serve configuration). Only one of the server pair may have write access
locked for these three files. It is also possible to share the other configuration data. If it is decided to share all
configuration data, then it is recommended that a policy be implemented where changes are always instituted from only
one member of the pair.
The primary of the fault-tolerant pair remains the primary until there is a failure of the process or the host. The pair
sends heartbeat (over an SSL link if desired) messages to each other to determine availability. If the secondary no
53
longer detects the primary, it will try and lock the files described above. If it succeeds in getting the file lock, it will take
over as the primary. If the secondary fails, it will continue trying to obtain the locks, or until it sees the primary heartbeat
messages again.
An EMS server can be configured as a fault-tolerant member or can be started as the fault tolerant member by
providing a command-line argument those points to the alternative servers URL or through setup in the main
configuration file (obviously not an option if the configuration data is shared). If it cannot find the alternative member,
and it can obtain a file lock on the relevant files, then it will start as the primary instead.
The client references the connection of a fault-tolerant pair through the connection factory. The factory can be obtained
through the JNDI store or can be manually created in the application. The fault-tolerant pair is referenced as a pair of
comma-delimited URLs, each pointing to the other member of the pair. This feature is again an EMS features, but the
connection factory is the JMS-specification-compliant mechanism for referencing connections to the vendor-specific
infrastructure; therefore, JMS has no specification for the arguments used with the connection factory. It is expected to
vary from vendor to vendor. Therefore, for portability reasons and centralized administration reasons, it is
recommended that applications obtain the connection factory information through the JNDI request (see 2.7 JNDI
Lookup for more details).
Once connected to the infrastructure, the JMS client application has no idea that there is a fault-tolerant pair of servers
under the covers. Should there be a failure of the primary, the EMS JMS library has been implemented to
transparently try and reconnect to the secondary. While it is possible to register interest in a special EMS message
indicating the failover occurred, without registered interest to this special message, there would be no knowledge on the
part of the client applications that the failover occurred (see Section 2.10.2 Client Fault-Tolerant State Transition
Trapping for details).
It is important to note that only those files that have been flagged as persistent will be available during a failover. Other
messages will not be available, as would have been the case if the single server failed and was restarted.
During a failover, the clients reconnect automatically to the secondary EMS server. It is possible to have the secondary
limit the time allotted for the clients to reconnect. The default is approximately 10 seconds. If the clients do not
reconnect in the allotted time period, the secondary server will clean up any state information for the clients that have
not reconnected, and consider those clients as down (see Section 2.10.1 Client Fault Tolerance and Delay in Failover
for more details on client reconnection and timing). Durable subscribers will still be able to recover messages and
accumulate new messages after the failover, if they are not reconnected in the allotted time frame. See Section 2.3.2.3
Durable Topics for more details on durable subscribers.
Essentially, the fault-tolerant setup of EMS servers allows availability of the JMS server without requiring full fault-
tolerant hardware. The only unique hardware requirement is that a shared storage area is required to make this feature
available in the design. It is also recommended that the network infrastructure be available and multi-port available
network interfaces be employed (for example IPMP (Internet Protocol Multi Path)) with connections to redundant
switches or hubs.
More details on fault-tolerant setup are available in the TIBCO EMS Users Guide.
3.3.1 Fault-Tolerant Server Element
The smallest production element should be the Fault-Tolerant Server Element (FTSE). The basic architecture
should be as follows:
54
The Fault-tolerant Server Element (FTSE) is comprised of three basic components:
! Primary Server Element (PSE) This is essentially a BSE that is operating as the primary member of
a fault-tolerant pair. It is expected that the PSE will reside on a different host than the SSE.
! Secondary Server Element (SSE) - This is essentially a BSE that is operating as the secondary
member of a fault-tolerant pair. It is expected that the SSE will reside on a different host than the
PSE.
! Shared Disk This can be a SAN, NAS, file server, dual-ported RAID array, etc. Unlike the BSE, the
FTSE requires visibility to shared media to operate.
The connection to the FTSE is transparent to the message consumers and producers. They operate with the
FTSE as if it was a single BSE.
3.3.2 Clustering
It is possible to load balance connections for both queue and topic destinations among EMS daemons to create a
cluster. This requires routes to be defined between the EMS servers (see Section 3.4.1 Server Routing for more
details on routing). The queues and topics must also be set to global or they will not be routed and available
among the routed EMS daemons. Connection to any member of the routed group is simply controlled through the
URL specified in the connection factory. The architecture is as follows:
55
A cluster is a routed collection of either FTSE or BSE. They can be mixed and matched. It is expected that for
most production environments FTSE will be used. The cluster is configured to appear as a single EMS server as
far as the application consumers and producers are concerned. The connection factories must be configured with
the URL syntax to indicate that there is load balancing among the BSE and FTSE components within the CSE.
It is recommended that one FTSE provide the JNDI store for connection, destination information. This will simplify
the administration since not all elements in the CSE will need to manually duplicate the same information.
Producers and consumers will be able to reference the appropriate information from the JNDI store to connect to
the least busy server in the cluster.
Clusters can provide load balancing for queues and topics. The same cluster can support multiple queue and topic
destinations. The cluster should also contain the required destination and protocol bridges. It is recommended that
the cluster support the destinations for a group of applications. The grouping is based on co-operative application
processing rather than geographic delineation. In fact, FTSE or BSE can be geographically dispersed as part of
the load-balancing architecture (see Section 2.3.2.1 Topic Message Routing for an example).
It is recommended that elements of the CSE be routed as a single zone, and make use of the single-hop mesh
routing configuration (this will need to be reviewed on a case-by-case basis -- a more complex routing
configuration may be required).
56
Connection to the cluster is based on a simple URL. The URL contains a list of EMS daemons that have routed
access to the same queue or topic across the daemon EMS server processes. Any number of EMS daemons can
be referenced. A vertical bar character delimiter separates the list. It is important to note that the connection URL
also allows reference to fault tolerant pairs of servers. For example:
tcp://server1:7777|tcp://server2prim:7777,tcp://server2sec:7777
The above URL allows load-balance access to a cluster of routed EMS daemons where the first daemon is not
using fault tolerance and is on host server1. The second element in the cluster is a fault tolerant pair of daemons
found on server2prim and server2sec.
The load balancing is connection-level load balancing. When the client connects, it will connect to the least busy
server. Servers can be determined to be busy based on one of two metrics: number of concurrent connections or
rate of bytes through the server. It is necessary to indicate the metric either through the JNDI reference. Likewise,
if the connection factory is manually created the connection metric must also be specified, or a load-balanced
connection to the cluster will not operate, even if the load-balanced URL is passed to the connection factory.
It is important to note, that there is no specialized process or application required to manage or control access to
the cluster or the fault-tolerant pair access. This eliminates the need for specialized devices such as load
balancers or other elements that would merely add cost, administration overhead and become another potential
bottleneck and point of failure to the architecture.
Load balancing is accomplished based on two possible connection metrics: number or connections to the server,
or the byte rate of messages through the server. It is important to note, that load balancing will only operate if the
metric is specifically defined. This is true for both local creation of the connection factory or through the JNDI
reference. For examples of using load balancing through factory creation, please refer to the EMS sample
programs included with the installation. The creation of the metric for JNDI reference through the EMS server can
be configured by either manually editing the referenced factory file (the default is factories.conf) or through the
administrator command line application (see the EMS Users Guide for the required syntax).
3.3.2.1 Clustering and a Service Bus Deployment
The Service Bus (SB) is a logical construct from the application perspective. The architecture is as follows:
Producer Consumer
M
e
s
s
a
g
e
M
e
s
s
a
g
e
Common
Service
M
e
s
s
a
g
e
A
d
m
i
n
M
e
s
s
a
g
e
A
d
m
i
n
M
e
s
s
a
g
e
A
d
m
i
n
M
e
s
s
a
g
e
Administration
Services
A
d
m
i
n
M
e
s
s
a
g
e
Service Bus
57
The bus itself is a collection of BSE, FTSE and/or CSE. The Bus has Services associated with it:
! Producer/Consumer Services these services are the JMS applications that are created or used by
the client. These applications can be a combination of custom code, non-coded applications or
COTS. Each service has two message interfaces: one for data messages, and another for
administration messages.
! Common Service In a Service Oriented Architecture (SOA), these are applications that are shared
by the producers and consumers. These could range from security services, to message mapping,
object repositories, etc.
! Administration Service This is the core of the local distributed administration service. An example
may be a Hawk-enabled Console application.
An SB is considered a complete application service. An example may be a Trade Services. An SB architecture
may be composed of several interconnected SBs. The SB can be comprised of one or more routed and
potential fault-tolerant pair clustered EMS daemon processes.
3.3.2.2 Clustering and an Enterprise Backbone (EB)
The Enterprise Backbone (EB) is a special Service Bus that provides centralized services that are potentially
used by any service on the individual SBs. The EB is also used as the major routing facility between the SBs.
The architecture is as follows:
Enterprise
Common
Service
M
e
s
s
a
g
e
A
d
m
i
n
M
e
s
s
a
g
e
Administration
Services
A
d
m
i
n
M
e
s
s
a
g
e
Central
Common
Service
Gateway
Services
M
e
s
s
a
g
e
A
d
m
i
n
M
e
s
s
a
g
e
M
e
s
s
a
g
e
A
d
m
i
n
M
e
s
s
a
g
e
Enterprise Backbone
R
o
u
t
e
d
M
e
s
s
a
g
e
R
o
u
t
e
d
M
e
s
s
a
g
e
Service Bus Service Bus
58
The main backbone is also comprised of BSEs, FTSEs or CSEs. The infrastructure will provide JNDI services
for enterprise-level resources. The actual backbone may be Server Elements that reside as part of the Service
Bus. It is necessary for a central administration resource to control routing between the Service Elements. To
eliminate hops, the option is there for the central administrator to define and administer the route. This implies
that for security reasons, only the central administrator can give access to the privileged admin account for
elements that are involved in routing.
Server elements that make up the backbone should be in their own routing Zone, and architects should
consider using multi-hop routing.
There are two requirements for Administration Services on the backbone. It must be able to monitor and
access the local services, as well as potentially provide centralized administration of elements or services on
the individual SBs.
The EB will also have some services that are best suited as part of a centralized enterprise-level services.
These include:
! Gateway Services This is where gateways between, for example, JMS and MQ-Series may reside.
This way, any application on any SB may get access. These gateways may also be between different
enterprise administration services such as between Hawk and OpenView.
! Enterprise Common Services Common services that are common to several SBs may be best
served from a central enterprise level.
! Central Common Services These are common services that are used by other services on the EB.
Again, the bus may be a collection of multiple routed and clustered EMS daemon processes.
3.3.3 Architectural Difference Between Project Stages
The previous section was directed more at a production environment than at test, quality assurance or
development.
In many cases, budget restrictions may result in all these project phases (except for production) being hosted on
the same machines. Development has the least stringent requirements for infrastructure. A simple BSE may
suffice for development.
Testing and QA will most likely require an FTSE or a simple CSE as described above. It will be necessary to test
all availability and load-balancing features.
It is also important for clients to standardize certain access structures to the elements to ensure that the different
project stages do not interfere with each other. Several options are available to ensure that, for example,
production data does not get polluted with test or development data. Suggestions and recommendations include:
! It is important to standardize the destination names within the different project phases. For
example, all destination names may be prefixed with the project phase.
! Do not use the same port for access between the server elements in the SB or EB for the
different project phases. For example, port 7777 is used for access to test services, 8888 for
production. In this way, there will be a physically different URL to access the EMS server
processes.
59
! Avoid using the same EMS servers for production and other project phases.
! Carefully control routing between production elements and other project-phase elements.
! Enforce the use of JNDI data stores to look up relevant information rather than making use of the
actual fully qualified destination names. Of course, this does not apply to dynamic destinations.
If EMS servers are shared among several project phases, the destinations must be different for the different
project phases.
3.3.4 Shared Storage System
Please refer to Section 3.3.4 Shared Storage System and 3.1.2 Storage Architecture for more details.
3.3.5 Disaster Recovery Design
In many cases, architects fall into the trap of believing that a disaster recover plan is merely an HA architecture
spread over a greater distance. This is not the case. Even with high-performance networks between the sites, the
limitations of the speed of light will start to greatly affect performance. The performance hit is a result of
propagation delay and the effects of this delay as it relates to the TCPs sliding window flow control.
As soon as the distance between the sites exceeds between 15 and 18 kilometers, plans for disaster recovery
become more complex to architect. One of the biggest issues the is duplication of the persistent messages at the
disaster site. Replication of the files is not a feasible option. Routing between the sites using EMS routing may
appear to help solve the issue, but it can be complex due to the fact there is no concept of pre-registration with
JMS topics.
These issues are not related to the TIBCO EMS implementation, but more of an issue that relates to the JMS
architecture. It is expected that a separate document will be produced to cover the details of disaster recovery and
JMS.
3.4 Design for Optimal Performance
Many potential scenarios need to be addressed by the messaging infrastructure. Control and administration of the
servers can either be centrally deployed or in a distributed architecture. Control and administration may also change
through the course of project development. For example, the project members may initially control administration.
However, in production there may be a requirement for a combination of local and central administrative control.
Applications and services can also be deployed as either part of a project or part of a centralized service offering. A
project may also make use of both local and centralized applications and resources. Regardless of the initial
architecture, change must be considered as part of the solution. The deployment is not necessarily going to be a static
entity.
Many of the aspects of the deployment models have already been addressed in the first several sections of this
document. Issues such as scaling, addressing, message interaction, etc. have been referenced and cross-referenced in
the first few sections of this document. Some of these issues must again be visited, but more from a deployment
perspective.
Several concepts have already been explored as guidelines (not hard-and-fast rules), and are key to the successful
deployment:
! A solid and consistent destination-naming scheme is a critical success factor in the deployment of
potential enterprise-level applications.
60
! Messages should ideally be designed as fire-and-forget data. Messages should be the union of
consumer requirements rather than an individual series of targeted messages.
! Topics should be considered as the message distribution mechanism of choice. Distributed, threaded,
asynchronous architectures provide greater efficiency than multiple point-to-point stovepipe
architectures. Using MOM technology to implement old client-server designs largely nullifies the
advantages of moving to a messaging architecture. Implementing old architectures over a messaging
infrastructure only provides a few small tactical and no real strategic advantages.
! Designs should ensure that the infrastructure usage is deterministic and efficient.
! It is assumed that scaling and load balancing is a requirement in the initial design and not an after-
thought or a Phase II requirement.
! Application instrumentation for administration access should be included in the initial design. This
allows administration tools to be used to solve issues that should not be hard-coded into the
application.
! Applications should be designed as part of a service-oriented architecture. MOM allows services to
be created on the messaging bus that are accessed by any application that requires that service. The
service is then expected to be deterministic, scalable and reliable. Monolithic do-everything-in-one-
application designs defeat the advantages a MOM infrastructure affords.
! Applications should not attempt to solve architectural issues that can and should be solved within the
messaging infrastructure (for example, the use of bridges rather than multi-message fan-out from the
client application).
! There is no single silver bullet design or solution for all application designs or deployment.
! Enabling features in the infrastructure or expanding the message overhead only when required,
rather than simply enabling everything for potential future use, achieves efficiency for the
infrastructure, the system resources and network utilization. Applications should be designed to allow
infrastructure directives and protocol data to be changed in real-time through administration interfaces
and from application startup directives.
! Authentication should ideally be validated against a centralized external store, such as LDAP (with
the exception of the EMS admin ID).
! Applications should be designed against the current JMS V1.1 programming model.
! Thresholds to prevent resource overflow should be the last line of defense as part of an application
design and not the only consideration for ensuring that an application does not overwhelm a
processing element.
! For portability reasons, vendor-specific infrastructure details that are defined by the JMS standard for
vendor use should be called via a JNDI binding to a data-store, rather than hard-coded.
! Application and infrastructure tracing, monitoring and potentially logging should be used judiciously in
production. Ideally, they should be enabled and disabled in a fine-grain manner through
administration and monitoring tools, through rule-bases and/or real-time interaction.
61
! Use of a single-vendor JMS infrastructure is recommended over several implementations and the
subsequent bridging. However, use of a vendor-specific implementation that acts as a wrapper for
purpose of integration may be a viable exception to consider if no COTS adapter is available.
! Default authorization should not be assigned to destinations. Only the access required for authorized
principals should be enabled.
! Principals (users) for both administration accesses and application destination access should be
assigned to groups to simplify access control.
! Persistent messages and durable topics should only be used when required. Disk access is the
limiting factor, and should be optimized to ensure peak throughput.
! Not all applications need to be created by writing programs. Non-coding solutions may have more
benefits and features and a potentially higher ROI than the coding alternative.
! Vendor-specific features that do not relate to infrastructure or require non-standard methods should
be avoided (such as non-standard message formats).
In addition to the points above, many best practices and design recommendations have been described in the first
sections of this document. It should be noted that these are guidelines and not rules.
3.4.1 Server Routing
Server routing is discussed in relation to queues and topics in Sections 2.3.2.1 Topic Message Routing and
2.3.1.2 Scaling and Performance Tuning of JMS Queues with EMS. The TIBCO EMS Users Guide also has a
very detailed description of server routing that will not be repeated in this document.
3.4.2 Destination Bridging
Destination bridging is a powerful feature available within the TIBCO EMS infrastructure. Bridging is the capability
of moving messages between queues and topics within the messaging infrastructure. In some cases the message
may be required by more than one destination and/or more than one destination type. This can be accomplished
from the application, but it will require a more complex connection configuration and will result in potentially the
same or similar message being sent more than once. Therefore, providing this type of application-level fan-out is
not recommended since it is complex and inefficient; it also defeats the design principal of fire-and-forget
messaging.
A bridge is a configuration created by an administrator on the EMS servers. Bridges are configured against
queues or topics. A bridge from a single queue or topic can be configured to fan out the message to several other
queues and/or topics. Bridged messages are not transitive; therefore, a message received from a bridged
configuration cannot be forwarded again even if the bridged receiver has another bridge configuration.
Bridges can also be directed to new destination names based on selector filters. The syntax for the bridge-selector
filter statement is the same as for queues and topics (see Section 2.2.2.4 Message Selectors). With bridge
selector statements there is overhead introduced into the messaging infrastructure. However, unlike the topic or
queue selector scenario, the performance is more predictable and deterministic, since it is enabled by the
administrator and not by any random application. The bridge also eliminates the need for custom-written
applications to perform the bridging function, which would most likely introduce the same or more overheads into
the infrastructure. Therefore, the use of selectors in the bridge configurations is not as critical an issue for
consideration as with consumer applications.
62
Bridging is a very powerful feature that will simplify application processing and design. It will eliminate the
requirement of applications needing to send the message multiple times because different destinations have
interest in the data. It also overcomes some of the performance issues associated with queues and consumer
performance (see Section 2.3.1.2 Scaling and Performance Tuning of JMS Queues with EMS). There are
numerous applications for bridges. Bridges will simplify application design and reduce the message traffic.
3.5 Client Management
3.5.1 Client Registration and Name Proliferation
There are three ways to create authentication credentials to be used for access to the EMS daemon:
! The server can register the user names and passwords either through the administration interfaces, or
through manual editing of the configuration files.
! The daemon can be configured to make use of the operating system login credentials.
! The daemon can authenticate against an LDAP repository.
If the server-registered credentials are used, it will require manual distribution to all servers where the same
credential is required. For this reason, this system works best for test and QA, but may not necessarily be
applicable for production environments.
With the operating system credentials, only the server where the credential exists will provide authentication. This
can be extended with operating-system-distributed authentication software. The use of operating system
credentials may not be acceptable for all companies security policy.
The LDAP alternative is perhaps the most popular mechanism for client credential authentication, and supports
multi-LDAP server synchronization.
For more details on this topic, please refer to Section 2.6.1 Infrastructure Authentication.
3.5.2 Client Authentication
Please refer to Section 2.6.1 Infrastructure Authentication.
3.5.3 Client Authorization
Please refer to Section 2.6.3 Application Authorization.
3.5.4 SSL Connections
Please refer to Section 2.6.5 Use of SSL and Authentication within EMS.
3.6 Server Management
3.6.1 Client Connection Management
The administration interfaces for EMS support the monitoring of which clients are connected to the servers. There
is also an indication if the credentials for the user are based on internal or external reference (see Section 3.5.1
Client Registration and Name Proliferation for more details).
63
EMS also supports several language bindings (see Section 3.9 Multi-Language Integration for more details).
Based on the bindings, there are limitations on potential interoperability between particular message types (see
Section 2.2.3 Message Payload Types for more details) and pure Java based JMS clients. Therefore, in some
cases, it is also important to know in what language the client application is written. This is also available through
the administration interface.
Clients that connect with administrator access and privilege (see Section 2.6.2 Administrator Authentication and
Authorization for more details) will be able to close client connections, and affect their use of daemon-managed
destinations.
Client connections are also configurable to support load-balanced connection to a cluster of routed EMS
daemons. Details can be found in Section 3.3.2 Clustering.
3.6.2 Message Persistence
Please refer to Section 3.1.2 Storage Architecture.
3.6.3 Server Scaling
Scaling of servers is a function of load balancing and performance tuning. Several performance-tuning
suggestions have already been made throughout the document up to this point. Suggestions varied from protocol
header usage, to queue routing, topic flow-control distribution and the use of bridges to move messages between
destinations.
Topics are also an excellent mechanism to provide scaling and load balancing when used in conjunction with
routing. As described in Section 2.3.2.4 Scaling and Performance Tuning of JMS Topics with EMS the use of
routing with topics also provides the capability to deal with geographic and network bandwidth issues.
With EMS, the capability of performing scaling is transparent to the client applications while still maintaining
compliance with the JMS specification. With topic or queue routing (please see relevant sections of the document
for more details), the client has the option to connect to potentially any one of several EMS servers and still have
access to the queue or topic messages for which the application has interest in interacting. Therefore, it is
possible to assign a connection to any one of these servers and still have visibility to the desired destinations.
Within the connection factory, (either called from the JNDI interface or constructed in the application) it is possible
to define a delimited list of possible servers to connect with. At time of connection, the servers determine the least
busy host and assign the actual connection to that host. It is important to note that the server list can have fault-
tolerant pairs listed as the potential hosts. Therefore, fault tolerance and load balancing at connection time can
both be attained with EMS servers.
The connection to the server is based on internal metrics that determine the load of the EMS servers at the time of
the connection request. This is not merely some simple round-robin DNS lookup. There is also no need for
dedicated load-balancing hardware or dedicated broker in the EMS solution, as is required by other JMS vendors.
As mentioned earlier, the use of JNDI lookups for the connection factory information is the recommended method
for clients to create connection factory references.
It is also possible to create a manual system to establish connection to the least busy server at connection time.
This makes use of the admin API for EMS. This is not necessarily recommended since this will require coding at
the client application level with the admin API. The admin API is not defined by JMS, and, therefore, this code will
not be portable. The benefits of creating a custom load-balanced connection request are minimal to the structure
implemented in the EMS servers. Nevertheless, it is available as an option.
64
3.6.4 Administration and Monitoring
Administration is a very broad topic. There are different administration and monitoring requirements depending on
the state of the project. There are different requirements for development (where detailed tracing is important)
than for production (where detailed tracing would cause an unnecessary processing burden).
There are also different requirements for different types of data. Some data needs to be logged and is used for
historical reference. Other data is used for real-time alerting of events. Some alerts require real-time programmatic
reaction to the data events to affect changes either in the infrastructure, the application or both.
There is also a different set of requirements between infrastructure monitoring and application monitoring. There
are also dependencies at the host, operating system, network and network infrastructure that will affect the
performance and behavior of the applications and messaging infrastructure. It is the sum of the administration and
monitoring of all these areas that are required to effectively perform root-cause analysis.
For example, on a host that is used to consume messages, assume that there is heavy swapping occurring
because of an out-of-memory condition. This condition may result in the EMS host enacting flow-control because
of a threshold storage condition. This flow control condition on the EMS host, caused by a memory condition on
the consumer host, will result in the producer on a third host being blocked from sending messages. If the alert is
generated from the third producer host, it will still not help an application administrator resolve the issue since it is
only a symptom of a problem and not the actual root cause. Even worse, if there is a separation of monitoring
duties, the application administration will have no visibility to the fact it is a hardware issue on a completely
different host. The administrator for the JMS consumer application may not be aware the alarm is the result of
another application on another host for which the JMS administrator may also have no visibility.
Separation of monitoring duties, and potentially administration duties, for the messaging infrastructure may not be
a viable strategy. While there is a requirement for domain expertise, tools used and setup for the domain expert
may overlap with other tools that already exist for other administrators or domain experts. If there is no integration
among these tools, then there is no choice but to potentially duplicate monitoring duties to ensure that the
messaging infrastructure and messaging clients can be maintained to provide industrial-strength quality.
There are solutions to all these issues, but it is beyond the scope of this document to make detailed
recommendations for a specific all-encompassing administration and monitoring strategy for the messaging
infrastructure.
Regardless, this section will provide a summary and provide examples of how many of the administration and
monitoring capabilities are addressed within the EMS infrastructure. This includes a description of what is exposed
for administration and monitoring capabilities. This section also explains what is available to automate the
processes and integrate with potentially existing tools and utilities.
3.6.4.1 EMS Command-Line Interface
EMS provides a command-line interface (CLI) that allows administrators to connect to the individual EMS
servers and interact directly with all the functions available in the EMS infrastructure. Access and permissions
to execute the administration commands is a function of the identity used to gain access the individual EMS
server. Roles can be assigned in a hierarchical basis, with a very fine-grain restriction for the individual
administrators administrative capabilities afforded through the CLI (please refer to Section 2.6.2 Administrator
Authentication and Authorization for more details).
65
The CLI is also valuable in the creation of administration and setup scripts. Scripts are a valuable tool used for
custom installation and configuration. The CLI will be a valuable asset in creating the required scripts.
It is important to note that the CLI updates the behavior of the EMS server in real-time. For example, if a new
topic is created through the CLI, the topic is immediately available for use, and the appropriate configuration
file is immediately updated. It is important to note that it is possible to manually edit the configuration file, but
the EMS server must be restarted before the server can use the new configuration.
CLI commands are used for other purposes than simply creating configuration files and modifying the behavior
of the EMS. The CLI commands also allow full administration of the running server to adjust conditions that
may affect performance. For example, an administrator can purge queues, delete or browse individual
messages, change the debugging and message tracing levels, etc.
Clients should not overlook the benefits of the EMS configuration files. For installation configurations, these
can be pre-configured and used for initial installations. This will reduce the detail and complexity of the
required installation scripts for the different application groups and administrators. The distribution of specific
configuration files may also be used a simple mechanism to provide bulk changes to a wide group of
configurations as an alternative to scripts that incorporate the CLI.
Details of the CLI and the setup of administrator access and all administration commands can be found in the
TIBCO EMS Users Guide.
3.6.4.2 Administration API
The JMS specification does not provide any standard references for an administration API. With JMS, it is
expected vendors will provide their own administration API. TIBCO has created an Administration API for use
with EMS. The API is for use with Java. More details are available in the HTML-based Java Docs that are
included with the EMS document distribution. There are several sample programs included with the EMS
software distribution to demonstrate the use of the administration API.
Rather than using scripts and the CLI, this API can be used to create programmatic interface to the EMS
administration function. One of the intentions of the admin API is to use this API to create GUI interfaces.
Another application is to use it as an integration API for use with third-party application monitoring and control
programs. TIBCO has used this API to build a service to allow Hawk to interact with the EMS administrative
interface. Please refer to the next section for more details.
3.6.4.3 Hawk Administration Software
Hawk is a pervasive administration and monitoring technology that is used by all of TIBCOs products. It has
evolved over 15 years of development. Hawk is not a single product, but a suite of monitoring and
administration tools. Hawk includes:
! TIBCO Hawk Agent and Inference Engine This is a process that provides the capability to perform
real-time interactive or rules-driven monitoring and automation of operations procedures. It provides
the ability to introspect all instrumented applications and monitor the exposed administration
interfaces. It also monitors system processes, log files, operating system parameters and protocols. It
allows instrumented applications to be monitored and controlled based on the state of the application
and the state of system resources. Instrumentation can be accomplished with a direct implant making
use of the Application Management Interface (AMI) or through using AMI in a proxy application. AMI
is a multi-language open interface for agent and rule-base access.
66
! TIBCO Hawk Console The console is built using the open Console API. It controls the monitoring
and management through the Hawk Agent. It is important to note that there are no rules in a Hawk
Console, as with most other monitoring and management systems. The rules run against the agent
locally. There is no need for a console to be present for the processing of rules; the agents do it all.
The Console application:
o Monitors all agents and associated micro-agents (state information and exposed
administration methods, both synchronous and asynchronous).
o Provides real-time interrogation and introspection of applications, processes, operating
systems parameters, file systems, etc. via the agent.
o Displays all alerts from the agents.
o Provides real-time manipulation of applications, operating systems, and file systems through
standard interaction with the agent and its micro-agents.
! TIBCO Hawk Adapters Adapters provide agent access to external components, which includes:
databases, SNMP agents and consoles, EMS servers, etc.
The EMS installation includes the adapter for EMS to interface directly to the Hawk Agent. This allows any
Hawk console application to interact and monitor the EMS server, and/or any JMS application that has a direct
Hawk Implant or a Hawk proxy based on the Hawk AMI.
The base Hawk Product includes a basic GUI-based Console application. However, clients are not limited to
this powerful but utilitarian Hawk Console product.
An HTTP adapter is available to allow Hawk console integration with any portal product. A screen shot of the
HTTP interface used in conjunction with the TIBCO portal is as follows:
67
TIBCO has also created an all-encompassing administration tool that makes use of Java Servlets and
integration with the Hawk Console API to create very powerful GUI-based administration tool. Not only can this
tool control most of TIBCO products (such as the applications created with Adapter SDK), but also controls
Business Works (see Section 3.7.1 Deploying EMS with BW 5.) and other TIBCO tools and utilities.
Below are three screen shots that only partially list the details of an EMS server as detailed from the single
General Tab in the TIBCO Administrator software:
68
69
Note that the Administrator software provides all the monitoring and command access available with the EMS
CLI, except through an HTTP servlet-driven interface.
There are also several third-party companies that integrate Hawk Agents into their visualization tools. They
have essentially taken the Hawk Console API and integrated their visual tools with the API. The result is the
capability for customers to easily create any custom visualization interface desired. Below are two interfaces
built with RT View technology:
70
This section provides only a sample of the use of Hawk and Hawk APIs to provide multiple powerful
visualization and monitoring tools for both the EMS infrastructure as well as applications used in conjunction
with the infrastructure.
Hawk also provides a powerful rule base that operates against the inference engine of the agent. This allows
the administrator to create powerful compound rules to automate operations of the infrastructure and the
applications that interface and use the EMS infrastructure.
For example, assume a producer application was created that supports the AMI Hawk API to provide
application instrumentation, in this case, the capability to allow the producer to introduce delay in the sending
of messages to the EMS server. A rule can be created that monitors the amount of disk being used for
persistent storage in the EMS server. If 75% of the storage is utilized, the rule could alert the producer(s) to
begin to slow the rate of message generation. When the threshold is again below 75%, the rule could indicate
that the producers may resume normal processing. This rule will proactively try and prevent the flow-control
threshold from being reached.
The logic for the processing behavior is exposed by the rule to the inference engine. Therefore, the distributed
operations logic is controlled through the rules XML meta-data rather than requiring it to be inflexibly coded
into the applications (which would require not only the logic of the rule, but a communications channel and
agreed-to message format among all participants as well). Hawk solves this application operations problem in
both TIBCO and non-TIBCO environments.
71
Rules are simple to create, modify and distribute. It is all accomplished through a simple GUI-interface and
requires no scripting or coding (although there is an API available should the client wish to create
programmatic interfaces to change rules).
More details on Hawk, Hawk integration, AMI, Console API, and all Hawk adapters can be found in several
TIBCO Hawk manuals. The TIBCO EMS Users Guide also describes the EMS Hawk interface and all the
exposed EMS methods available through Hawk.
3.6.4.4 Integration with Other Administration Interfaces
Several options are available to use other administration tools and interfaces. There are other notable suites of
management and administration tools available from other vendors, such as HP that has the OpenView
product suite that includes a wide range of tools from SNMP consoles to root-cause analysis tools, correlation
engines, etc. Other significant vendors in this arena include CA and BMC.
TIBCO provides a bi-directional interface between Hawk and Enterprise Management platforms such as HP
OpenView using standard management interfaces. The current support is for Web Services Management
Framework (WSMF) v1.20.13. WSMF is a management framework that provides a consistent and secure
mechanism based on Web Services.
Hawk also supports bidirectional integration with any SNMP management console through the SNMP adapter.
This provides the processing and generation of SNMP traps, as well as polling SNMP agents for integration of
information in use with Hawk Rules.
Hawk also has the capability of writing events to log files for monitoring by other administration and monitoring
systems. Conversely, Hawk can also monitor log files created by other systems. Log files are sometimes the
only alternative for integration between monitoring systems if there is no API exposed.
EMS also provides the capability of generating trace and log files directly, which can be used as a rudimentary
integration tool to other management and administration systems.
It is also possible to use the EMS Administration API to create custom gateways between EMS and
administration tools used by the client. This is the technique used with Hawk. Rather than putting an implant
into an EMS server, a gateway was created using the EMS administration API and Hawk AMI. In this way, the
EMS server would not be complicated with AMI if the administrator was not making use of Hawk-based tools.
It is also significant to note that Hawk supports integration with JMX application controls.
3.6.4.5 Tracing of the EMS Server
Tracing of server events can be enabled on the EMS server. There are several classes of data for which the
EMS server can provide tracing services, including:
! Access Control
! Administration
! Routing
This data can be sent to the console or logged to file, or both. Log files can be set to only grow to a maximum
size. When this size is reached the file is copied to a rotated file, and logging continues until the file again
reaches its maximum specified size.
72
EMS provides fine-grain control capabilities for tracing that can be enabled to monitor the EMS server. There
are over 20 server trace options available. EMS provides a default group of options that can be enabled as
well.
It is not recommended that all server event-tracing options be enabled against the EMS server. They should
only be enabled as required, or there will be a horrendous amount of detail generated; this will only complicate
searches for specific information. If all server event-trace options are enabled, looking for specific information
becomes like drinking from a fire hose.
The more server tracing options that are monitored or logged, the more the impact on the performance of the
EMS server. It should be used judiciously for production environments. The production server tracing options
should be enabled during performance prototyping to provide a more accurate production performance metric.
Adjusting monitoring and logging options during prototyping will also indicate the impact of the tracing options
during production.
It is important to note that the server trace options can be enabled and disabled through the CLI or through
Hawk-aware applications. Therefore, clients could use Hawk rules to enable or disable server tracing only
when certain conditions or situations occur, thereby automating the tracing capabilities of EMS.
Tracing can also be enabled through command-line arguments when starting the EMS server. This works well
in development and testing where the configuration files are to remain static, but for brief, interrupted periods,
the behavior for tracing is necessary to be modified.
3.6.4.6 Message Tracing
The EMS server can also provide detailed tracing of messages that flow through the server and not just server
events as described above. This is particularly valuable for application debugging, development and testing.
Tracing can be set against messages or destinations.
Destination tracing can be enabled at various levels including when:
! messages are received into the destination;
! messages are sent to the consumer;
! messages are exchanged with other messaging infrastructures (Rendezvous or Smart Sockets);
! messages are acknowledged;
! messages are sent across destination bridges;
! messages are routed;
! messages sent to temporary destinations.
The application also has the capability to cause the EMS server to enable message-level tracing. This is
accomplished by setting the JMS_TIBCO_TRACE property (see Section 2.2.2.1 Provider-Specific
Properties for more details). Depending on the value of the property set in the optional JMS header, either just
header information is recorded or the header and message payload.
Message tracing also will introduce non-deterministic processing overhead to the EMS server, and therefore
should only be used judiciously in production. Tracing messages based on destination also can be controlled
through the CLI interface or through Hawk-aware applications. Therefore, the same recommendations and
suggestions as described in the previous section also apply.
73
It is also recommended that clients expose the messaging tracing capability through an administration API
such as Hawk AMI. This will allow the application to enable or disable tracing though administration or rule-
base control.
3.6.4.7 Monitoring Server Events through Topics
An alternative to the monitoring capabilities described in Section 3.6.4.5 Tracing of the EMS Server, EMS
also provides special topics that are populated with server event messages. As with regular topics, no
messages are written to these special topics unless a consumer specifically registers interest in these
messages. Therefore, there is no inherent overhead until these topics have consumers. The larger the number
of topics that have consumers associated with them, the greater the overhead incurred by the JMS server.
Monitoring of event topics is an excellent way of starting and stopping monitoring events that do not require
any administration implants or access via the CLI or EMS administration API. Simply registering as a
consumer results in the server generating the relevant messages to the topic. Dynamic topics are used;
therefore, the more detailed the topic name the more fine-grain the messages and monitored events (see
Section 2.4 Temporary, Dynamic and Static Destinations for more details on dynamic topics).
More than 24 wide-grain events can be monitored through these special topics. All monitor topics begin with
the prefix: $sys.monitor. Finer control can be used through the level of the topic name. For example,
monitoring $sys.monitor.connection.disconnect would only allow the consumer to receive alerts when a client
disconnects. Monitoring the topic $sys.monitor.connection.* would allow the consumer to receive all client
connect and disconnect event messages. Notice again, how wild cards can be very valuable.
It is most definitely not recommended for clients to create a topic consumer with the topic $sys.monitor.>.
This would result in the capture of all monitoring events.
The beauty of these special system-level dynamic topics is that they allow standard JMS applications to be
used to create specific EMS management applications. Because these topics are no different than any other
dynamic topic, access control and permissions can be assigned by the administrator to ensure only authorized
consumers can get access to these topics. Again, no specialized administration commands need to be utilized
to provide hierarchical administration access to these server events. The same scheme as described in
Section 2.6.3 Application Authorization can be applied.
The use of system topics is an excellent mechanism to implement applications such as security audits or
recording historical EMS server events. The use of non-programming development tools (such as TIBCO
Business Works) to interface with these queues provides a rapid ability to create audit and event logs that are
recorded to centralized client data stores.
More details on system monitor topics can be found in the TIBCO EMS Users Guide.
3.6.4.8 EMS Server Statistics
EMS has the capability of generating statistics for rates of events and messages that pass through the server.
The server details can be accessed through the CLI or Hawk-enabled applications such as TIBCO
Administrator. Customers can also create their own applications based on the EMS Administration API to
create custom statistics-monitoring applications.
By default, the statistics are updated and recalculated every three seconds; however, this can be altered.
There is a wide array of events for which statistics are maintained. The gathering of statistics does not provide
much overhead on the EMS servers performance. Statistic gathering can be set at the default levels, or a
greater level of detail can be gathered by simply modifying a single server-configuration file entry.
74
Server statistic information is only stored in memory of the EMS server. If persistent statistic history is required,
it must be extracted from the server through an admin API or Hawk-enabled application or tool.
3.7 Deploying EMS with Other TIBCO Components
3.7.1 Deploying EMS with BW 5.X
Up to this point, all discussions assumed that all interfaces to the messaging infrastructure would be via programs
developed either as stand-alone applications. There are other environments available to develop applications that
do not require coding, or the process of application development is reduced to virtually no coding. These
applications provide the capability to model the entire process flow and workflow as well as all the integration,
message mapping and exception processing. These applications provide engines that then allow the applications
to run directly against the design.
Examples of this include products such as TIBCOs Business Works (BW). BW, for example, can be used to
create the adapters, bridges and even complex applications, without the use of coding. An example can be used
to demonstrate a simple process flow that simultaneously sends a static message to an EMS topic, an EMS queue
and makes use of JMS for IBM MQ-Series to immediately send a message MQ as well. This example can be
created in less than a half an hour.
The process flow is created by first simply dragging the messaging forms from a palette and filling in the required
details. For the EMS connection the main form for JMS was:
The advanced features tab displayed the following form information:
75
Notice that the details for the JMS communication forms are simply the details that would be used for the
connection factory, connection and topic and queue connections within an application. SSL could have also been
configured just as easily.
Communications with JMS to MQ-series was also just another simple form to fill in:
Note that the only differences are with the vendor-specific components of the JMS JNDI connection factories to
obtain the necessary information from the two different JNDI stores.
At this point, the process flow was created to deliver the messages. The flow was modeled as follows:
76
At this point, the application was complete. The Publishers and queue senders simply were configured to
reference the already configured messaging elements, and everything was ready to run. Running the application
put the same message in all three places.
This shows the basis of a simple application that could act as simple bridge between JMS vendors as described in
section. The same tools could also have been used to provide integration to EJB environments and other
component models or applications, with full monitoring, process flow, exception handling, and message mapping,
etc.
These tools are an alternative to creating programs that interface with the JMS environment. Clients should
consider BW as an alternative to writing custom code. They are excellent alternatives for shared messaging
services.
3.8 Interacting with Other JMS Providers
It is recommended that clients restrict the number of JMS vendor implementations that are employed as part of the
messaging solution. One should be used for the main messaging infrastructure. Others can be integrated as necessary.
The nature of JMS allows a single vendors JMS to be used with all JMS applications. The use of a single vendor
provides the cleanest implementation from a support and administration perspective.
There is no vendor interoperability with JMS at the wire-level, so integration or adapters at this level is not an option.
Integration at the application level is a possible mechanism to integrate between two JMS vendors. For example, if
access is required to IBM MQ-Series and the EMS infrastructure, it is possible to create connections via JMS to both
environments from the same JMS application. This is possible since the details of the vendor-specific connections are
hidden in the connection factory details, allowing connection to both from the same application. (This is only one
alternative that is suggested as a discussion point. TIBCO also has available a COTS MQ adapter. Regardless, using
JMS as a common interface to two messaging infrastructures (EMS and MQ) is possible where the alternate messaging
infrastructure is in production and provides a JMS wrapper over their standard messaging interface in this case the
MQ API suite).
A second integration alternative is via a JMS-level adapter, where a JMS application is created that acts as a gateway
to bridge the two infrastructures. These gateways (also sometimes called bridges) would best be deployed as shared
resources rather than being assigned to each application that required access.
77
An example of the connection factory and setup to use BW to create a JMS bridges is provided in the previous section
of this document. But unlike the previous example, one connection would be as a consumer, the other as a producer (in
the previous example, both are producers).
Regardless of the mechanism deployed, it will require more investigation before detailed designs can be created.
It is important to note that some JMS vendors provide COTS JMS bridges between different vendors of JMS.
Unfortunately, they are rather generic and generally do not take into consideration things such as JMS message
vendor-specific properties that aid in the control of the JMS infrastructure, thereby nullifying some of the other vendors
value added capabilities.
3.9 Multi-Language Integration
Obviously, JMS is a message API specification to support a standard interface for Java applications to interface to the
vendor-specific MOM. Unfortunately, a Java-only interface to the messaging infrastructure is not necessarily a viable
alternative. Not everyone has expertise with Java, and forcing all developers to learn Java is not necessarily a
reasonable solution. Although Java is a robust programming platform, TIBCO is making use of EMS as a full messaging
platform, not just a JMS-centric environment.
Therefore, EMS also has support for C and C# as programming languages that support message exchange with all
JMS-compliant Java applications. As a result, JMS clients can interact with C and C# clients through EMS on a native
level and without modification. There are some interoperability restrictions that are language-binding-specific. For
example, JMS specifies byte and object message types. Obviously. A Java object reference and C object reference are
not compatible (for more details see Section 2.2.3 Message Payload Types).
The C and C# attempt to mimic the JMS specification for message creation, wire format and interaction with
destinations.
Java provides the capability of making use of programs that are written in other languages through the JNI interface.
While this is an option, it is not recommended to write the programs in another language and then using JNI to bind
them to Java and the EMS infrastructure. It would be complicated and still require potential re-mapping of the message
formats.

Ems Best Practices

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Ems Best Practices

Загружено:

Авторское право:

Доступные форматы

http://www.tibco.

Вам также может понравиться