Ems Best Practices

8/21/2019 Ems Best Practices

1/77

http://www.tibco.com

Global Headquarters3303 Hillview Avenue

Palo Alto, CA 94304Tel: +1 650-846-1000Toll Free: 1 800-420-8450Fax: +1 650-846-1005

Copyright 2004, TIBCO Software Inc. All

rights reserved. TIBCO, the TIBCO logo, The

Power of Now, and TIBCO Software are

rademarks 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

his 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.


2/77

TIBCO EMS Best Practices

2

Table of Contents

1 INTRODUCTION.........................................................................................................................................................4

1.1 EMS DEVELOPMENT BACKGROUND.....................................................................................................................41.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 ........................................................................................................................92.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 ......................................................................................................................................112.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 .................................................................................................................132.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....................................................................................................................................192.2.6 Message Encryption .......................................................................................................................................19

2.3 QUEUES VS. TOPICS .............................................................................................................................................21

2.3.1 EMS Queue Infrastructure .............................................................................................................................222.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 ..............................................................................................................................262.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.........................................................................................................................322.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/77


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 .............................................................................................................................442.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 ......................................................................................................................................483.1.2.1 Storage Hardware...................................................................................................................................................48

3.1.2.2 File Systems............................................................................................................................................................48

3.1.3 Physical Server Architecture .........................................................................................................................483.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 .......................................................................................................................................................543.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 .................................................................................................623.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 .....................................................................................................................643.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/77


4

1 Introduction

1.1 EMS Development BackgroundEMS 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 dominatedthe 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/77


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 DevelopersApplication 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/77


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 Javacode 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 distr ibution 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 TeamThe 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/77


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 GuruUnderstanding 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 DocumentThe 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 PracticesTIBCO 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/77


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 notfocus 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 StandardThere 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 MessagesAlthough 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 JMSBody

Standard Properties

ApplicationProperties

Provider Properties


9/77


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 FieldsThe 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-delimitedstring 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/77


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 administrat ion 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/77


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 modecan 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 FieldThis 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/77


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/77


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 FieldsMessage 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/77


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 theadministration 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 withoutjeopardizing interoperabil ity 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/77


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 PropertiesThe 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/77


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 goodreference 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/77


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 TypesJMS 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 thedesign 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/77


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 FormatsJMS 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/77


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 CompressionMessage 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 EncryptionThe 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 becreated 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/77


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/77


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

ProducerMessageMessage

EMS

Server


22/77


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 withthe 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/77


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 theprocessing 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/77


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

p

Ems Best Practices

Documents

Transcript of Ems Best Practices