Sunday, December 13, 2009

TIB/Adapter Applications and TIB/MessageBroker

custom adapter has to work together with an application-independent transformation engine to provide full adapter functionality.
  • The adapter's primary functionality is to retrieve data from and export data to a source or target application such as an ERP (Enterprise Resource Planning) application.
  • Transformation and routing functions are performed by a message transformation engine like TIB/MessageBroker or other transformation product.

A custom adapter created with the TIB/Adapter SDK changes the format of the data so it can be understood by a variety of other applications. Although a source application's data model can be complex, the adapter retains much of the source information and makes it easy to access.

However, a custom adapter does not change the content of the data, so two applications might still not be compatible. For example, the name and address of a customer might be stored in five fields in one ERP application and in six fields in another. This kind of content conversion must be performed by a tool like TIB/MessageBroker or a third-party, message transformation system enabled for TIB/Rendezvous.

TIB/MessageBroker transforms data and provides a graphic interface for creating and modifying data transformation rules. The adapter pushes data out of a third party application (for example SAP R/3). TIB/MessageBroker can then transform the data to formats understood by other adapters (for example TIB/Adapter for Clarify, TIB/Adapter for PeopleSoft, or custom adapters).


Sunday, December 6, 2009

TIB/Adapter SDK Advantage

The TIB/Adapter SDK promotes rapid development and ensures that adapters built using it have the same external interface and that they plug into the overall ActiveEnterprise product suite in a consistent manner.

Using the TIB/Adapter SDK to create a custom adapter has the following advantages:

  • A set of reusable components that aids in rapid development of your custom adapter, with few constraints placed on the development process.
  • Consistent external interface to adapters and applications built using the SDK:
  1. Consistent configuration data and metadata representation through the SDK TIB/Adapter Administrator tool. The tool is explained in TIB/AdapterAdministrator User's Guide.
  2. Common mechanisms for reporting (MTrace and MSink classes and MAdvisoryDocument and MBusinessDocument classes.)
  3. Standard application and session (transport) management (MApp and MRvSession)

Common means of configuring, transforming, and routing data (import and export)

  • Compatibility with other applications in the TIBCO ActiveEnterprise product suite.
  • Integration with TIB/Hawk (SDK 2.x is compatible with TIB/Hawk 2.x; SDK 3.x is compatible with both TIB/Hawk 2.x and TIB/Hawk 3.x).


Sunday, November 29, 2009

What are adapters? About TIB/Adapter SDK

They are components that enable application integration. They integrate applications with TIB. Their functions include:
  • Data representation mapper
  • Establish connectivity
  • Support for common communications paradigms
  • API hiding

Adapters and the TIB/Adapter SDK

A TIB/Adapter integrates an application in an event-driven, decoupled manner with the rest of the enterprise. Specifically, the adapter integrates third-party software with TIBCO ActiveEnterprise applications.

TIBCO Software Inc. has already released a number of adapter products such as TIB/Adapter for R/3, TIB/Adapter for Clarify, and TIB/Adapter for PeopleSoft. You can buy these products to integrate the respective application with TIB/Rendezvous and ultimately with your event-driven enterprise. You can also use the TIB/Adapter SDK to build a custom adapter for the application you need to integrate.

The TIB/Adapter SDK

All TIBCO adapter products are built on top of the TIB/Adapter SDK, and you can use the SDK to build an adapter of your choice.

The SDK is a class library that allows developers to implement an adapter for their source or target application with minimal effort. The SDK itself encapsulates much of the required behavior; developers implement certain methods and subclasses and specify configuration and metadata information as appropriate.


Monday, October 26, 2009

Configuring Rendezvous to Use a Different Port: Starting rvd Manually & Creating a Shell Script

Use the -listen option when launching rvd to specify the port to be used. This can either be done manually (at the command line), or by setting up a shell script that automates the process.

Starting rvd Manually
Start rvd from the command line as follows:

rvd -listen tcp:PORT_NUMBER

In this command line, PORT_NUMBER is the port on which you wish rvd to listen. This port should match the port specified for the Netcool/Precision IP processes.

Creating a Shell Script
To create a shell script to automate the process for each time you use rvd:
  1. Move the rvd binary to a new location, for example, rvd.exe.
  2. Create a shell script with the filename rvd and execute permissions for the user that will run Netcool/Precision IP. Use a command that contains the following lines:

#!/bin/shrvd.exe -listen tcp:PORT_NUMBER

In this command PORT_NUMBER is the port number to be used. This port number must match the port specified for the Netcool/Precision IP processes. Every subsequent call to rvd is now a call to this shell script.

The shell script must be started manually due to checking features that are built into rvd itself. Consequently, if you are configuring ncp_ctrl to launch rvd, you must specify the executable itself (which is now rvd.exe if you have followed the above steps), and use the -listen argument, as specified above, rather than specifying this shell script.


Wednesday, October 21, 2009

Connecting to the Rendezvous Daemon Running on Another Machine

In this case there is no need to install Rendezvous. Edit the NCHOME/etc/precision/Precision.rvd.cfg configuration file to ensure that it contains the following statements:

rendezvous session for host 'LOCAL_HOST_NAME' =
{ 'service' = 'PORT_NUMBER' 'network' = 'INTERFACE_NAME/IP_ADDRESS' 'daemon' = 'tcp:LOCAL_IP_ADDRESS:PORT_NUMBER'

Where PORT_NUMBER is the number of the port to be used (for example, the default rvd port number 7500), INTERFACE_NAME/IP_ADDRESS is the name or IP address of a non-loopback network interface (for example,, and LOCAL_IP_ADDRESS is the IP address of the local machine.


Wednesday, October 14, 2009

Configuring Rendezvous for Distributed Components

By default, Rendezvous uses the loopback interface, that is, it does not broadcast traffic over the subnet. If you want Netcool/Precision IP components on one machine to communicate with components on another machine, you must configure Rendezvous to use the network interface.

To configure Rendezvous to use the network interface, edit the NCHOME/etc/precision/Precision.rvd.cfg configuration file to ensure that it contains the following statements:

rendezvous session ={

'service' = 'PORT_NUMBER'




Where PORT_NUMBER is the number of the port to be used, INTERFACE_NAME/IP_ADDRESS is the name or IP address of a non-loopback network interface (for example,, and LOCAL_IP_ADDRESS is the IP address of the local machine.


Sunday, October 4, 2009

Monitoring System Resources

Two useful system metrics for monitoring system resources are CPU utilizationand free memory. If either of these metrics is compromised, the system is probably not running optimally and requires attention.

To monitor CPU utilization:
  • Microsoft Windows: Use the Performance microagent and the System method, and check the %Total Processor Time result field.
  • UNIX: Use the System microagent and the getCpuInfo method, and check the % System Time or % User Time result field. You could also check the %Time Idle field for low values.

To monitor overall memory usage:

  • Microsoft Windows: Use the Performance microagent and the Memorymethod, and check the Committed Bytes or % Committed Bytes in Use result field. To check swap file usage, use the Performance:Paging File()method and check the % Usage and % Usage Peak result fields.
  • UNIX: Use the System:getSwapInfo


Tuesday, September 29, 2009

Controlling Execution of TIBCO BW services

  • Process instances typically remain in memory as long as they are executing an activity. If the process instance is waiting for an incoming event (for example, a Wait for Adapter Message activity), the process instance can be paged out to disk and resumed later after the event arrives.
  • New process instances are paged out to disk until there is available memory and resources to accommodate them.
  • Use TIBCO admin to control execution of TIBCO BW process instances. Useful if system has limited resources & memory or to restrict process instances to run sequentially.

Go to --> Application Mgmt --> Application configuration --> click proccess service -> Advanced Tab

  • Max Jobs : Specifies the maximum number of process instances that can concurrently be loaded into memory. Any process instances created once the maximum is reached must be paged out to disk.
  • Activation Limit : Specifies that once a process instance is loaded, it must remain in memory until it completes. useful if you wish to specify sequential processing of incoming events, or if you want to enforce limited concurrent execution of process instances.
  • Max Jobs (FLow Limit) : Specifies the maximum number of currently running process instance to start before suspending the process starter. Max Jobs (Flow Limit) field limits the number of process instances created by a process starter. This allows you to control the flow of processing so that incoming events are no longer accepted when the limit is reached. This is useful in protocols like TIBCO RVCM, JMS Durables TOpic, JMS Queue, Recceive Mail etc.


Wednesday, September 23, 2009

Main Responsibilities of TIBCO Admin Server

  1. Manage Storage for the domain -- Storage can be file based repository or in a database repository.
  2. Enforce Security for the domain -- User authentication & authorization
  3. Provide Load balancing -- each domain can be configured with one primary & multiple secondary servers. Primary server allows read & write operations while secondary servers only supports read operations.
  4. Provide Failure recovery -- When primary server is down, secondary server continue serving.


Monday, September 21, 2009

Elements of TIBCO Admin domain

  1. Administration Server - Manages admin domain.Each administration server manages only one domain. Multiple secondary servers are allowed. Server can be accessed with web browser based TIBCO Administrator.
  2. Machines - By default all machines in an admin domain are expected to be in same subnet. However TIBCO RVRD can be used to communicate to the machines on different subnet.
  3. User & Acces Information - stored in domain repository. Also syncronize with LDAP server for users & groups
  4. Runtime Application - Start, stop & monitor individual process engines & service instances.
  5. TIBCO Hawk Agent -- Monitors local resources & conditions. Hawk Agent is an autonomous process & uses collection of locally loaded rules organized into rulebases to apply monitoring logic.


Thursday, September 17, 2009

Overview of TIBCO Administrator

Functions of TIBCO Administrator:

  1. User Management -- creates users & roles, assign them access rights to TIBCO Admin console, application & application repository
  2. Resource Management -- manage TIBCO software installed on other machines in domain & monitors machines in domain
  3. Application Management -- upload, deploy & monitor applications

TIBCO Administrator Architecture includes:

  • Tomcat web server -- manage basic communiaction & makes TIBCO Admin available
  • Administrator Server -- Manage domain & application repositories
  • User Management
  • Resource Management
  • Application Management


Wednesday, September 9, 2009

Using Stylesheets in XML- CSS & XSLT

XML is a means of exchanging data between applications. It allows the developers to describe and structure their data in their own formats. As the XML gave more emphasis on data rather than formatting, the data in the XML document can be formatted in two ways:


Cascade Style Sheet( CSS):

Initially, Cascading Style sheets (CSS) were used for formatting the data in the XML documents. It allows the Web Developers to define a formatting for the elements in XML and the same can be applied to as many documents you like. The advantages are:

  • It has a Precise control over presentation
  • It is Resolution Independent
  • It downloads Faster
  • It is easy to maintain

Though it has a lot of advantages it also has following disadvantages.

  • The order of elements for display cannot be changed
  • An element cannot be processed more than once
  • Generated text cannot be added to the presentation

Extensible Stylesheet Language (XSL):

The difficulties that were encountered with CSS were removed by making use of XSL. XSL is an application of XML It allows you to create high performance XML based systems by integrating Server side XML processing’s. The need for transforming data from one format to the other results in splitting XSL into two groups:

  1. XSLT – It describes how to transform XML. Document into other formats.
  2. XSL-FO- It describes formatting details of each element in the XML document.


The XML Style sheet Language Transformation (XSLT) is a mechanism of transforming one form of XML documents to the other form. It is a set of templates based on Xpath expressions that tells how to fetch a particular node from the XML documents. It is a part of XSL, which is a style sheet language for XML. XSLT is widely used in Websites Content Management to convert XML into HTML pages. It uses Xpath to define parts that match one or more templates. Xpath is an query language that allows you to identify the nodes. It can select nodes in any direction. An XSLT processor is used to perform transformations of XML document in to other formats based on the given XSLT document.


XSL-FO means Extensible Formatting Objects. There are two different ways in which the XML document can be formatted. They are:

  • Layout Based formatting
  • Content Based formatting

In a layout based formatting, the limitations of the target may constrain the content or appearance on the page, whereas in a Content Based Formatting, the target medium is generated to accommodate the information being formatted. The XSL FO allows you to make formatting and styling options to your document.


Sunday, September 6, 2009

Is XML a Database?

XML document is a collection of data. In other words it doesn’t make much difference between the other files that store data. A XML in a database format is a self describing, portable, and can describe data in tree or graph structure. XML is a sort of Database Management System (DBMS).

XML provides storage, schemas, query languages, programming interfaces and so on .It lacks in triggers, queries, multi-user access that a real database constitutes. The main advantage of XML is that the data is portable and it allows you to have nested entries.

XML allows you to preserve physical document structure, supports document level transactions and execute queries in an XML query language.

Mapping the XML document schema to the database schema does the transfer of data between XML documents and a database. Mappings between document schemas and database schemas are performed on attributes and text. There are 2 mappings that are generally used to map on XML document schema to the database schema:


Native XML databases are designed especially to store XML documents .It is always possible to store data in XML documents in a native XML database. This is done so, when your data is semi-structured. Although, this kind of data can be stored in object oriented and hierarchical databases, it is always better to store it in a native XML database. It enables us to retrieve data much faster than a relational database. One more reason is to store data in a native XML database is to exploit XML specification capabilities, such as executing XML queries.


Monday, August 31, 2009

What is XML and What Good is XML?

What is XML?
XML stands for eXtensible Markup Language and is a descendant of Standard Generalized Markup Language (SGML), just as HTML is. The most noticeable difference between XML and HTML is the fact that you can define your own tags in XML. That is why XML is considered an extensible language. Because of the freedom of the tags, however, the way in which XML must be written is very strict. Every tag must have a closing tag and all nodes must be ordered properly. If any of these rules are broken, an XML document will simply fail to function. HTML, as many have found, will work even if the document only vaguely looks like an HTML document.

What good is XML?
XML is all about structure. The markup in XML defines what the data represents (i.e. The Catcher in the Rye). HTML, on the other hand, is made for publications. Hence, in HTML, it makes sense to order information by where and how it will appear on the screen. In XML, however, the structure of the information is what's most important. The order of the information is unimportant - it can be displayed in whatever order you want. The important thing is that each piece of data is contained in markup that describes what that data really represents. The structure can be maintained much more easily in XML because of the fact that you can create your own tags.

Think of a book you've read recently. The chapter titles were most likely in bold print. We come to rely on these sorts of conventions to give us a sense of the structure of the document. When you're dealing with a web page, you have to make the structure evident to the reader to help them deal with the information. By using XML, you can easily keep track of information like chapter titles because they will all be contained in markup designating what they are (i.e. Ch. 1 - The Beginning). You can then choose to display that information in whatever way will make it easiest for your reader.

That's what XML is all about: structure.


Wednesday, August 26, 2009

Basic Principles of Service Orientation Architecture (SOA)

To build an SOA solution based on Web services, you need to follow the service-orientation principles when pulling the services together into an application. Here are some of the key principles of service-orientation you need to keep in mind when designing SOA solutions:

  1. Loose coupling: It represents a relationship that allows the underlying logic of a service to change with minimal or no impact on the other services utilized within the same SOA. Loose coupling is the key principle of service orientation. Implementing services as loosely coupled pieces of software allows you to keep up with the other key principles of service orientation, such as service reusability, service autonomy, and service statelessness.
  2. Service contract: It represents service descriptions and other documents describing how a service can be programmatically accessed. In the Binding with WSDL section earlier in this article, you saw an example of a WSDL service description document that describes a service, defining the contract for that service.
  3. Abstraction of underlying logic: It means that a service publicly exposes only logic described in the service contract, hiding the implementation details from service consumers.
  4. Autonomy: It means that services control only the logic they encapsulate. Dividing application logic into a set of autonomous services allows you to build flexible SOA solutions, achieving loose coupling, reusability, and composability.
  5. Reusability: Reusability in service-orientation is achieved by distributing application logic among services so that each service can be potentially used by more than one service requestor. Building reusable services supports the principle of composability.
  6. Composability: Composability represents the ability of services to be grouped into composite services that coordinate an exchange of data between services being aggregated. For example, using an orchestration language, such as WS-BPEL, allows you to compose fine-grained services into more coarse-grained ones.
  7. Statelessness: It means that services don't maintain their state specific to an activity. Building stateless services encourage loose coupling, reusability, and composability.
  8. Interoperability: Interoperability between services is easily achieved as long as the services interact with each other through interfaces that are platform- and implementation-independent.
  9. Discoverability: Discoverability refers to standard mechanisms that make it possible for service descriptions describing services to be discovered by service requestors. Universal Description, Discovery, and Integration (UDDI) specification provides such a mechanism, which allows for publishing service descriptions documents in an XML-based registry, thus making them available for public use.

As you can see, most of these principles are tightly related. For example, if you bear the autonomy principle in mind when dividing application logic into services to be utilized within an SOA, you will have reusable, composable, and loosely coupled pieces of software that can be reused in future projects.

On the other hand, ignoring at least one principle of service-orientation makes it very hard to keep up with the others. For example, if you ignore the principle of statelessness when designing services, you will end up with less reusable and less composable building blocks for your SOA solutions.


Monday, August 24, 2009

Introduction to Service-Oriented Architecture

While using Web services allows you to achieve interoperability across applications built on different platforms with different languages, applying service-oriented concepts and principles when building applications based on using Web services can help you create robust, standards-based, interoperable SOA solutions.

It is interesting to note that Service-Oriented Architecture, while providing architectural foundation for building service-oriented solutions, is not tied to a concrete technology or technology set. In contrast, it may be implemented with various technologies, such as DCOM, CORBA, or Web Services. However, only the Web Services technology set is currentlythe primary way to put SOA into practice.


Thursday, August 20, 2009

What is WSDL and Its Benefits

WSDL is an XML document used to describe web services and WSDL stands for Web Services Description Language.

A WSDL document defines services as collections of network endpoints, or ports. In WSDL, the abstract definition of endpoints and messages is separated from their concrete network deployment or data format bindings. This allows the reuse of abstract definitions: messages, which are abstract descriptions of the data being exchanged, and port types which are abstract collections of operations. The concrete protocol and data format specifications for a particular port type constitutes a reusable binding.
  • Types– a container for data type definitions using some type system (such as XSD).
  • Message– an abstract, typed definition of the data being communicated.
  • Operation– an abstract description of an action supported by the service.
  • Port Type–an abstract set of operations supported by one or more endpoints.
  • Binding– a concrete protocol and data format specification for a particular port type.
  • Port– a single endpoint defined as a combination of a binding and a network address.
  • Service– a collection of related endpoints.

The primary benefit of the WebService behavior is that it provides a simple way for you to call methods that are exposed by Web Services using the SOAP protocol. The WebService behavior enables you to call a remote method using a few, straightforward, client-side scripting methods exposed by the behavior. Navigating to another URL is unnecessary when using the WebService behavior to deliver data to a page because DHTML is used to update the page's content. This approach enhances the browsing experience significantly, compared to traditional browsing approaches that require a full page refresh.


Monday, August 17, 2009

TIBCO BusinessConnect Remote Overview

TIBCO BusinessConnect Remote is a light-weight software application designed to exchange business documents exclusively with a BusinessConnect server overthe Internet using the AS2 transport. It allows large enterprises to enable their small partners to start performing E-commerce transactions rapidly, with minimal setup, and relatively at low cost.

TIBCO BusinessConnect Remote client service is a protocol that enables the BusinessConnect Remote client to download the configuration data from a BusinessConnect server in preparation for a secure document exchanges upon startup. The configuration data includes exchange of certificate credentials forencryption and digital authentication between the BusinessConnect Remote client service and the BusinessConnect server as well as the AS2 transport parameters.

The audit log viewer for the BusinessConnect Remote client service captures the audit trail of the startup request initiated by each BusinessConnect Remote client.For more information about the audit log, see TIBCO BusinessConnect TradingPartner Administration Guide, Appendix C, BusinessConnect Remote Client.

For the complete information about this application, see TIBCO BusinessConnect™Remote User’s Guide.


Wednesday, August 12, 2009

Data Stores in BusinessConnect

BusinessConnect uses two types of data stores:

  1. Runtime data store
  2. Configuration store

By default, the data stores use the default database connection. You can assign adifferent database to the data stores using the window System Settings > JDBCConnections.

1. Runtime Data Store

The runtime data store tracks the information flowing through the engine,recording the same information that can be recorded in audit andnon-repudiation logs plus information about hibernation, database locking,resend, and alert messages.

This information, however, is for use by the BusinessConnect engine itself,serving as a memory of what tasks it has already performed. BusinessConnectcannot function without a valid runtime database.

2. Configuration Store

The configuration store records all the information that you provide toBusinessConnect. For example, it stores information about business partners,configuration parameters, and transport settings.


Monday, August 10, 2009

BusinessConnect Server Components

TIBCO BusinessConnect server is internally divided in two components:

1. DMZ (De-Militarized Zone)

This component sits in the de-militarized zone and can have several restrictions on the networks it can access.

The DMZ component receives B2B communications directly from the Internet and performs SSL validation. By placing a firewall between the DMZ and the rest of your system, you can protect against the threat of malicious communications.

2. Interior Engine

This component performs the following tasks:

(i) Handles all messaging level activities such as encryption, decryption, and digital signatures.

(ii) Takes care of business level logic to be executed by an individual protocol, such as document schema validation.

Any deployment configuration change should trigger redeployment of both server components.


Thursday, August 6, 2009

BusinessConnect product Overview and Major Features

BusinessConnect is a B2B (business-to-business) gateway that allows your company to engage in electronic commerce with your partners. It enables secure transmission of documents and messages between partners using disparate internal business systems.

BusinessConnect supports multiple protocols (also called standards) for electronic commerce, such as EDI, RosettaNet, and SOAP.

BusinessConnect includes these major features:

  • BusinessConnect Server engine, which handles transport, messaging, and business message content
  • Trading partner management system and certificate store
  • Non-repudiation database
  • Audit log database
  • Two deployment options: Single Server and Dual Firewall DMZ mode
  • BusinessConnect Palette for TIBCO BusinessWorksTM

BusinessConnect uses TIBCO AdministratorTM as its graphical user interface, making it especially familiar and easy-to-use for existing TIBCO customers.

Business agreements, an essential component of any B2B implementation, can be easily constructed with BusinessConnect. A business agreement defines the protocol (or protocols) you will use to exchange documents with your partner.

It defines the transport method (for example, HTTPS or email), and the operations that each partner will be allowed to transact. When you set up operations at the system level for use with multiple partners, BusinessConnect gives you the flexibility to override individual aspects of an operation as needed for specific partners.


Friday, July 31, 2009

Using the configuration Files in EMS

The configuration files contain information about the various EMS objects like queues, topics, users, bridges etc. These files are located in TIBCO_HOME/ems/bin directory.

These files can be edited either directly using a textpad or using the command line based administration tool. The administration tool will eventually read/write to/from these configuration files.

Following are the key configuration files that are available in EMS server:

tibemsd.conf - This is the main configuration file. It has properties that are concerned with the EMS server.

queues.conf - Queue configuration file.

topics.conf - Topics configuration file.

users.conf - All users configuration file.

acl.conf - Permission settings for users on destinations.

routes.conf - Routes configuration file.

bridges.conf - Bridges configuration file.

factories.conf - Connection Factories configuration file.


Wednesday, July 29, 2009

Wildcards in Topics and Queues

The wildcard * means that any token can be in the place of *.
For example: foo.* matches all two-part destination names beginning with foo. including and, but not

The wildcard > matches one or more trailing elements. For example, foo.> matches and

Wildcards in Topics:
  • You can subscribe to wildcard topics.
  • You cannot publish to wildcard topics.
  • If is not in the configuration file, then you can publish to if foo.* or foo.> exists in the configuration file.
Wildcards in Queues:

You can not send or receive to wildcard queue names. However, you can use wildcard queue names in the configuration files.

For example, if the queue configuration file includes a line:
foo.* then users can create queues, foo.bob, and so forth, but not


Monday, July 27, 2009

Key Interfaces in EMS - MessageProducer, MessageConsumer and MessageListner


A MessageProducer object is created by a Session object and is used for sending messages to destinations. For example, using the mySession object created in Session , the following creates a MessageProducer that sends messages to a queue named myQueue:

MessageProducer myQueueSender = mySession.createProducer(myQueue);

Once you have created a MessageProducer, you can use it to send messages. For example, the following sends a message using the queueSender created above:


You can create MessageProducers that do not identify a destination. When the sender or publisher does not specify a destination, you must specify the destination when you send or publish a message as the first parameter of the send() or publish() method.


A MessageConsumer object is created by a Session object and is used for receiving messages sent to destinations. For example, using the mySession object, the following creates a MessageConsumer that retrieves messages from a queue named myQueue:

MessageConsumer myQueueReceiver =

For queues, messages remain on the queue until they are consumed by a MessageConsumer, the message expiration time has been reached, or the maximum size of the queue is reached.

a) Durable Subscribers for Topics: Only MessageConsumers whose client applications are running receive messages published on a topic. Optionally, Sessions can create durable subscribers to ensure that messages are received, even if the application is not currently running.

(b) Synchronous or Asynchronous Messages: The API allows for synchronous or asynchronous message consumption. For synchronous consumption, the MessageConsumer explicitly calls the receive() method on the topic or queue. For asynchronous consumption, the client registers a MessageListener for the topic or queue. When a message arrives at the destination, the TIBCO Enterprise Message Service server delivers the message by calling the listener’s onMessage() method.


A MessageListener object acts as an asynchronous event handler for messages. This object implements the MessageListener interface and has one method, onMessage().The onMessage() method is called by the TIBCO Enterprise Message Service server when a message arrives on a destination. You implement the onMessage() method in your MessageListener class to perform the desired actions when a message arrives. Your implementation should handle all exceptions, and it should not throw any exceptions.

Once you create a MessageListener object, you must register it with a specific MessageConsumer. The following creates a queueListener (an implementation of the MessageListener interface) and registers it with the QueueReceiver object:

MessageListener queueListener = new MessageListener();

You should register the MessageListener with the MessageConsumer before calling the Connection’s start () method to begin receiving messages.


Saturday, July 25, 2009

Key Interfaces in EMS - ConnectionFactory, Connection and Session


The ConnectionFactory object encapsulates a set of connection configuration parameters. When a client starts, it typically performs a Java Naming and Directory Interface (JNDI) lookup for the ConnectionFactories that it needs. For example, the following code retrieves the InitialContext using the JNDI properties specified by env, then looks up a ConnectionFactory named myConnectionFactory.

Context ctx = new InitialContext(env);
ConnectionFactory myConnectionFactory =
(ConnectionFactory) ctx.lookup("myConnectionFactory");


A Connection object encapsulates a virtual connection with the server.
ConnectionFactory objects create Connection objects. You use a Connection to create one or more Session objects. For example, the following creates a Connection:

Connection myConnection =

When a client application completes, all open connections must be closed. Unused open connections are eventually closed, but they do consume resources that could be used for other applications. Closing a connection also closes any Sessions created by the Connection. To close a connection, use the close() method. For example:


A Session is a single-threaded context for producing or consuming messages. You create MessageProducers or MessageConsumers using Session objects. For example, using the myConnection object created in Connection above, the following creates a Session:

Session mySession =

myConnection.createSession(false, Session.AUTO_ACKNOWLEDGE);

The first parameter to the CreateSession() method determines whether the Session is transactional or not. The second parameter specifies the acknowledge mode of messages received by the session.

The remaining Key Interfaces will be explained in tomorrow's posting.


Friday, July 24, 2009

Destination Bridges, Routes and Flow Control

Destination bridges and flow control

Please read Bridges before reading this topic

Flow control can be specified on destinations that are bridged to other destinations. If you wish the flow of messages sent by way of the bridge to slow down when receivers on the bridged-to destination cannot process the messages quickly enough, you must set the flowControl property on both destinations on either side of the bridge.

Routes and flow Control
For global topics where messages are routed between servers, flow control can be specified for a topic on either the server where messages are produced or the server where messages are received.

If the flowControl property is set on the topic on the server receiving the messages, when the pending message size limit is reached, messages are not forwarded by way of the route until the topic subscriber receives enough messages to lower the pending message size below the specified limit.

If the flowControl property is set on the topic on the server sending the messages, the server may block any topic publishers when sending new messages if messages cannot be sent quickly enough by way of the route. This could be due to network latency between the routed servers or it could be because flow control on the other server is preventing new messages from being sent.


Thursday, July 23, 2009

Control access to the EMS Server:Authentication and Permissions

TIBCO Enterprise Message Service allows you to control access to the server by creating users and assigning passwords, creating groups, setting permissions etc. The server can also authenticate users defined in an external directory (such as an LDAP server)

Permissions for all users and groups must be defined in the access control list for the TIBCO Enterprise Message Service server. There are also administrator permissions that allow administrators to control which actions users can perform on the server such as create destinations, modify users, and view routes. Administrator permissions can apply globally, or they can be granted on specific destinations.

Enabling Access Control
There are two levels where authorization is set.

Server: The authorization property in the main configuration file enables or disables the checking of permissions for all destinations managed by the server. The authorization property also enables or disables verification of user names and passwords.

To enable authorization, edit the tibemsd.conf file:
authorization = enabled

From the command line admin utility:

set server authorization = enabled

If this is not set, then the server allows any client connection and no permissions are checked on any destination. Enabling authorization immediately applies to existing client connections (except route connections). The server begins checking permissions.

Destination: The secure property of the destinations is used to allow the server to check permissions of a client connection for that particular destination when a user attempts to perform any operation on that destination

Setting Permissions
Permissions are stored in the access control list and determine the actions a user can perform on a destination. Permissions can only be granted by users that have the appropriate administrator permissions.

Please go through the corresponding chapter in the JMS documentation for further detailed information


Tuesday, July 21, 2009

Failover in EMS

Step 1
A backup server detects a failure of the primary in either of two ways:
  • Heartbeat Failure—the primary server sends heartbeat messages to the backup server to indicate that it is still operating. When a network failure stops the servers from communicating with each other, the backup server detects the interruption in the steady stream of heartbeats.
  • Connection Failure—the backup server can detect the failure of its TCP connection with the primary server. When the primary process terminates unexpectedly, the backup server detects the broken connection.

When a backup server (B) detects the failure of the primary server (A), then B attempts to assume the role of primary server. First, B obtains the lock on the current shared state. When B can access this information, it becomes the new primary server.

  • If B cannot obtain the lock immediately, it alternates between attempting to obtain the lock (and become the primary server), and attempting to reconnect to A (and resume as a backup server)—until one of these attempts succeeds.
  • When server A comes back again, it becomes a backup server and server B continues to be the primary.
  • Clients of A that are configured to failover to backup server B automatically transfer to B when it becomes the new primary server.

Step 3:

After a failure, message redelivery is attempted based on the type of messages and destination configuration.

  • Persistent: When a failure occurs, messages with delivery mode PERSISTENT, that were not successfully acknowledged before the failure, are redelivered.
  • Failsafe: EMS guarantees that a message with PERSISTENT delivery mode and a failsafe destination will not be lost during a failure.
  • Any messages that have been successfully acknowledged or committed are not redelivered, in compliance with the JMS 1.1 specification.
  • All topic subscribers continue normal operation after a failover.
  • Queues: For queue receivers, any messages that have been sent to receivers, but have not been acknowledged before the failover, may be sent to other receivers immediately after the failover. A receiver trying to acknowledge a message after a failover may receive the javax.jms.IllegalStateException. This exception signifies that the attempted acknowledgement is for a message that has already been sent to another queue receiver.
  • After a failover, attempting to commit the active transaction results in a javax.jms.TransactionRolledBackException. Clients that use transactions must handle this exception, and resend any messages sent during the transaction.


Monday, July 20, 2009

Configuring the Fault Tolerant Servers

To configure an EMS server as a fault-tolerant backup, set these parameters in its main configuration file (or on the server command line):
  • server Set this parameter to the same server name in the configuration files of both the primary server and the backup server.
  • ft_active In the configuration file of the primary server, set this parameter to the URL of the backup server. In the configuration file of thebackup server, set this parameter to the URL of the primary server.

When the backup server starts, it attempts to connect to the primary server. If it establishes a connection to the primary, then the backup server enters standby mode. If it cannot establish a connection to the primary, then the backup server assumes the role of the primary server (in active mode). While the backup server is in standby mode, it does not accept connections from clients.

To administer the backup server, the admin user can connect to it using the administration tool

When a backup server assumes the role of the primary server during failover, clients attempt to reconnect to the backup server (that is, the new primary) and continue processing their current message state. As each client reconnects, the backup server reads its message state from the shared state files. You can instruct the server to clean up state information for clients that do not reconnect before a specified time limit.

The ft_reconnect_timeout configuration parameter specifies that time limit (in seconds). The default value is 60 seconds


Saturday, July 18, 2009

Fault Tolerance in EMS

You can arrange TIBCO Enterprise Message Service servers for fault-tolerant operation by configuring a pair of servers—one primary and one backup. The primary server accepts client connections, and interacts with clients to deliver messages. If the primary server fails, the backup server resumes operation in its place. (EMS does not support more than two servers in a fault-tolerant configuration.)

Shared State: A pair of fault-tolerant servers must have access to shared state, which consists of information about client connections and persistent messages. This information enables the backup server to properly assume responsibility for those connections and messages.

Server state includes 3 categories of information:

  • Persistent messages

  • Client connections of the primary server

  • Metadata about message delivery (stored in the meta.db file)

Persistent messages are stored in 2 files: async-msgs.db file, which contains all the messages stored under normal mode, and sync-msgs.db file that contains all messages that are for failsafe destinations

Locking: To prevent the backup server from assuming the role of the primary server, the primary server locks the shared state during normal operation. If the primary server fails, the lock is released, and the backup server can obtain the lock.

Click to read about Configuring Fault Tolerance.


Thursday, July 16, 2009

EMS Message Delivery Mode Extensions (Reliable Message Delivery): PERSISTENT and NON PERSISTENT

TIBCO Enterprise Message Service(EMS) introduces two types of message delivery which are extensions to the JMS specification.

JMS delivery requirements ensure the delivery of all messages in almost all circumstances. However this requirements leads to a lot of overheads in the sense of network traffic (message and a return message confirming the receipt of the message) and the memory allocated for each persistent message and durable subscriber.

For higher throughput, EMS has come up with 2 ways of reducing the above overheads:
  • Reliable Message Delivery
  • No-Acknowledgement Delivery receipt

Reliable Message Delivery:

JMS has PERSISTENT and NON_PERSISTENT delivery modes for both topic and queue. In addition to these modes, you can use Tibjms.RELIABLE_DELIVERY mode from TIBCO Enterprise Message Service.

PERSISTENT and NON_PERSISTENT delivery require the server to return a system message to the client application to ensure proper handling of messages. In reliable delivery mode, the client application does not wait for this system message. Thus, reliable mode decreases the volume of message traffic, allowing better usage of system resources, and higher message rates.

No-Acknowledgement Message Receipt:

In no-acknowledge receipt mode, after the server sends a message to the client, all information regarding that message for that consumer is eliminated from the server. Therefore, there is no need for the client application to send an acknowledgement to the server about the received message. Not sending acknowledgements decreases the message traffic and saves time for the receiver, therefore allowing better utilization of system resources.


Wednesday, July 15, 2009

Undelivered Message Queue in EMS

If a message is to be removed from the system in any way besides being properly consumed by a message consumer, the server checks the message for the JMS_TIBCO_PRESERVE_UNDELIVERED property.
When JMS_TIBCO_PRESERVE_UNDELIVERED is set to true, the server moves the message to the undelivered message queue.

This undelivered message queue is a system queue that is always present and can not be deleted.


Tuesday, July 14, 2009

Message Acknowledgements in EMS

This post is the continuation of the Previous posts, So please read those also.
There are 3 levels of acknowledgements:
  1. DUPS_OK_ACKNOWLEDGE, for consumers that are tolerant of duplicate messages.
  2. AUTO_ACKNOWLEDGE, in which the session automatically acknowledges a client’s receipt of a message.
  3. CLIENT_ACKNOWLEDGE, in which the client acknowledges the message by calling the message’s acknowledging method.

The following describes the steps in message delivery and acknowledgement:

  1. A message is sent from the message producer to the machine on which the TIBCO Enterprise Message Service server resides.
  2. The EMS server acknowledges that the message was received.
  3. The server sends the message to the consumer.
  4. The consumer sends acknowledgement to the server that the message was received.
  5. In many cases, the server then confirms acknowledgement to the consumer. Acknowledgement from the consumer to the server prevents the delivery of duplicate messages.


Monday, July 13, 2009

Message delivery modes- persistent and non-persistent

JMS defines two message delivery modes, persistent and non-persistent. This mode is set by the message sender or publisher in the JMSDeliveryMode message header field.

Non-Persistent messages are never written to persistent storage. Persistent messages are logged to persistent storage when they are sent. Messages with the persistent delivery mode are always written to persistent storage, except when they are published to a topic that has no durable subscribers. When a topic has no durable subscribers, there are no subscribers that need messages resent in the event of a server failure. Therefore, messages do not need to be saved, and performance is improved because disk I/O is not required.


Thursday, July 9, 2009

Bridges between Destinations

You can create bridges between destinations so that messages sent to one destination are also delivered to all bridged destinations. Bridges are created between one destination and one or more other destinations of the same or of different types. That is, you can create a bridge from a topic to a queue or from a queue to a topic.

Why Bridge destinations?
Some applications require the same message to be sent to more than one destination, possibly of different types. For example, an application may send messages to a queue for distributed load balancing. That same application, however, may also need the messages to be published to several monitoring applications. Another example is an application that publishes messages to several topics. All messages however, must also be sent to a database for backup and for data mining. A queue is used to collect all messages and send them to the database.

Bridges are not transitive and they are uni-directional. That is, if there is a bridge between A to B, then message sent to A can only flow to B and not the other way. Similarly, if there is a bridge between destination A to B and another bridge between destination B and C. Then any message sent to A will flow to B but not to C.

  • Selecting Messages: By default, all messages sent to a destination with a bridge are sent to all bridged destinations. This can cause unnecessary network traffic if each bridged destination is only interested in a subset of the messages sent to the original destination. You can optionally specify a message selector for each bridge to determine which messages are sent over that bridge.
  • Access Control: Message producers must have access to a destination in order to send messages to that destination. Messages can only be sent to bridged destinations to which the message producer has access.
  • Transactions: When a message producer sends a message within a transaction, all messages sent across a bridge are part of the transaction. Therefore, if the transaction succeeds, all messages are delivered to all bridged destinations. If the transaction fails, no consumers for bridged destinations receive the messages.


Wednesday, July 8, 2009

Destination(Queues & Topics) Properties-5

This post is the continuation of the Previous posts, So please read that properties also.

12. exclusive: Only Queues
It defines how the server delivers messages to queue consumers when multiple queue consumers are present. In exclusive mode, the first queue consumer receives all of the messages until the consumer fails. At that point, messages are delivered to the next consumer. The first queue consumer is the first-activated queue receiver.

With non-exclusive queues (exclusive set to false) the server distributes messages in a round-robin—one to each receiver that is ready. If any receivers are still ready to accept additional messages, the server distributes another round of messages—one to each receiver that is still ready. When none of the receivers are ready to receive more messages, the server waits until a queue receiver reports that it can accept a message. This arrangement prevents a large buildup of messages at one receiver and balances the load of incoming messages across a set of queue receivers.

13. prefetch: Only Queues
Delivering messages from the server to a client program involves two independent phases—fetch and accept:
1. The fetch phase is a two-step interaction between a MessageConsumer object (in a client program) and the server.
  • The MessageConsumer initiates the fetch phase by signalling to the server that it is ready for more messages.
  • The server responds by transferring one or more messages to the client, which stores them in the MessageConsumer object.

2. In the accept phase, client code takes a message from the MessageConsumer object.
To reduce waiting time for client programs, the MessageConsumer can prefetch messages—that is, fetch a batch of messages from the server, and hold them for client code to accept, one by one. It can improve performance by decreasing or eliminating client idle time while the server transfers a message.

Different values,
prefetch=none, disable automatic prefetching
prefetch=0, inherit from the parent or set default value which is 5prefetch=n, prefetch n number of messages from server

14. expiration
The server’s expiration property overrides expiration values set by message producers (in client programs). You can set this property for any queue and any topic.
If this property is set for a destination, then when the server delivers a message to that destination, the server replaces the producer’s expiration value with this value.


Tuesday, July 7, 2009

Destination(Queues & Topics) Properties-4

This post is the continuation of the Previous posts, So please read that properties also.

9. import: Both Queues and Topics
The import property allows messages published by an external system to be received by a TIBCO Enterprise Message Service destination (a topic or a queue), as long as the transport to the external system is configured. Currently you can configure transports for TIBCO Rendezvous reliable and certified messaging protocols. You can specify the name of one or more transports of the same type in the import property.

10. export: Only Queues
The export property allows messages published by a client to a topic to be exported to the external systems with configured transports. Currently you can configure transports for Rendezvous reliable and certified messaging protocols. You can specify the name of one or more transports of the same type in the export property.

11. maxRedelivery: Only queues
The maxRedelivery property specifies the number of attempts the server should make to redeliver a message sent to a queue. The value of this parameter can be set to an integer between 2 and 255. Once the server has attempted to deliver the message the specified number of times, the message is either destroyed or it is placed on the undelivered queue, if the JMS_TIBCO_PRESERVE_UNDELIVERED property on the message is set to true.

Note:The remaining Properties of Destinations will be posted in coming days, Please check for this blog updates daily to keep in touch.


Monday, July 6, 2009

Destination(Queues & Topics) Properties-3

This post is the continuation of the Previous posts, So please read that properties also.

6. sender_name_enforced: Both Queues and Topics
The sender_name_enforced property specifies that messages sent to this destination must include the sender’s user name. The server retrieves the user name of the message producer using the same procedure described in the sender_name property above. However, unlike, the sender_name property, there is no way for message producers to override this property.

7. flowControl: Both Queues and Topics
The flowControl property specifies the target maximum size the server can use to store pending messages for the destination. This is useful when message producers send messages much more quickly than message consumers can consume them. You can specify the flowControl property without a value to set it to the default of 256KB. Flow control must be enabled for the server before the value in this property is enforced by the server.

Setting flow Control
First enable flow control by setting flow_control=enabled in the tibemsd.conf file. Then set the flowControl property to the desired value (in bytes) on that destination.

How it works
When the storage for pending messages is near the specified limit, the server blocks all new calls to send a message from message producers. The calls do not return until the storage has decreased below the specified limit. Once message consumers have received messages and the pending message storage goes below the specified limit, the server allows the send message calls to return to the caller and the message producers can continue processing.

8. trace: Both Queues and Topics
Specifies that tracing should be enabled for this destination. This property can be specified as either trace or trace=body. Specifying trace (without =body), generates trace messages that include only the message sequence and message ID.

Note:The remaining Properties of Destinations will be posted in coming days, Please check for this blog updates daily to keep in touch.


Saturday, July 4, 2009

Destination(Queues & Topics) Properties-2

This post is the continuation of the Previous post, So please read that properties also.

3. maxBytes: Both for Queues and topics
This property is useful for limiting the pending messages on each destination.
For Queues, it defines the maximum size (in bytes) of all messages that can be waiting in the queue. By default, or if maxbytes is set to 0, there is no limit to the size of a queue. If a receiver is off-line for a long time, maxbytes limits the memory allocation for the receiver’s pending messages. Messages that would exceed the limit will not be accepted into storage and an error is returned to the message producer.

For Topics maxbytes limits the total size (in bytes) of all messages waiting for delivery to each durable subscriber on that topic. The limit applies separately to each durable subscriber on the topic. For example, when a durable subscriber is off-line for a long time, pending messages accumulate in the server; maxbytes limits the memory allocation for those pending messages for the subscriber; when the subscriber consumes messages (freeing storage) the topic can deliver additional messages.

4. global: Both Queues and Topics
Messages destined for a topic or queue with the global property set are routed to the other servers that are participating in routing with this server.

5. sender_name: Both Queues and Topics
If this property is set on the destination, then server copies the username of the client to the message header property: JMS_TIBCO_SENDER. However if the tibco sender sets the property JMS_TIBCO_DISABLE_SENDER, it can override the behavior of sender_name and the sender name will not be copied by the server.

Note:The remaining Properties of Destinations will be posted in coming days, Please check for this blog updates daily to keep in touch.


Friday, July 3, 2009

Destination(Queues & Topics) Properties-1

Destination properties are properties that can be applied to queues and/or topics that describe specific behavior of the destination. Each property is described in short and please refer the EMS documentation for deeper understanding.

1. Failsafe: For Both Queue and Topic

TIBCO Enterprise Message Service provides two modes for persisting topic/queue messages in external storage. These two modes are:

  • normal
  • failsafe

In Normal mode all persistent messages are written to the storage in an asynchronous mode, ie data may be in the system buffers for a short duration before written to the disk.

Whereas in failsafe mode, data is not retained in the buffers and written to the disk synchronously. This ensures that in case of any software or hardware failure data is not lost.

In situations where loss of data is not acceptable, use failsafe. One should keep in mind that failsafe mode is a performance hit and should analyze and carefully use this property based on the need.

2. secure: Both for Queue and Topic

The secure property, when set on a destination, specifies permissions should be checked for that destination. When a topic or a queue does not have the secure property turned on, any authenticated user can perform any actions with that topic or queue. When the property is turned on, the administrator can assign permissions to the users. For this property to work, the authorization property must also be enables at the server level configuration file.

Note:The remaining Properties of Destinations will be posted in coming days, Please check for this blog updates daily to keep in touch.


Thursday, July 2, 2009

TIBCO EMS Destinations:Queues & Topics

Destinations for messages can be either Topics or Queues. A destination can be created statically in the server configuration files, or dynamically by a client application.

Static Queues and Topics
Static Queues and topics are administered by the server. The configuration information is stored in the configuration files for the Tibco EMS server, which is located in TIBCO_HOME/ems/bin folder. The files are queues.conf and topics.conf. Changes to the configuration information can be made in a variety of ways. To manage static destinations, you can edit the configuration files using a text editor or you can use the administration tool. An EMS Client retrieves the destination information from the JNDI.

Dynamic Queues and Topics
Dynamic queues and topics are created on-the-fly by applications using
QueueSession.createQueue() and TopicSession.createTopic(). Dynamic
queues and topics do not appear in the configuration files, and exist as long as there are messages or consumers on the destination. A client cannot use JNDI to lookup dynamic queues and topics.When you use the show queues or show topics command in the administration tool, you see both static and dynamic topics and queues. The dynamic topics and queues have an asterisk (*) in front of their name in the list of topics or queues.

Temporary Queues and Topics
Servers connected by routes exchange messages sent to temporary topics. As a result, temporary topics are ideal destinations for reply messages in request/reply interactions.

To read Properties of destinations ClickHere


Popular Posts

  © Blogger templates The Professional Template by 2008

Back to TOP