TIBCOEMSBestPractices15Feb2005

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