A client must connect to a running instance of the EMS server to perform any JMS operations. A connection factory is an object that encapsulates the data used to define a client connection to an EMS server. The minimum factory parameters are the type of connection (e.g.
, ’generic’ for JMS 1.1 connections an
d ’topic’ o
r ’queue’ for JMS 1.0.2b connections) and the URL (host name, transport protocol and port id) for the client connection to the EMS server.
A connection factory is either dynamically created by the application or obtained from a data store by means of a naming service, such as a Java Naming and Directory Interface (JNDI) server or a Lightweight Directory Access Protocol (LDAP) server.
EMS provides a JNDI implementation that can be used to store connection factories. Java, C, and C# clients can use the EMS JNDI implementation to lookup connection factories.
You can also store connection factories in any JNDI-compliant naming service or in an LDAP server. Java clients can lookup connection factories in any JNDI-compliant naming service. C and C# clients use LDAP servers.
Looking up Administered Objects Stored in EMS describes how to lookup a connection factory from an EMS server. How to create connection factories in a EMS server is described in
Creating and Modifying Administered Objects in EMS.
Normally client applications use JNDI to look up a Connection Factory object. However, some situations require clients to connect to the server directly. To connect to the EMS server directly, the application must dynamically create a connection factory.
The following examples show how to create a connection factory in each supported language for JMS 1.1 connections. Each API also supports connection factories for JMS 1.1 XA connections.
In each example, the serverUrl parameter in these expressions is a string defining the protocol and the address of the running instance of the EMS Server. The serverUrl parameter has the form:
See the tibjmsMsgProducer.java sample client for a working example.
See the tibemsMsgProducer.c sample client for a working example.
See the csMsgProducer.cs sample client for a working example.
By default, a client will attempt to connect to the server two times with a 500 ms delay between each attempt. A client can modify this behavior by setting new connection attempt count and delay values. There are also a number of factors that may cause a client to hang while attempting to create a connection to the EMS server, so you can set a connection timeout value to abort a connection attempt after a specified period of time. For best results, timeouts should be at least 500 milliseconds. EMS also allows you to establish separate count, delay and timeout settings for reconnections after a fault-tolerant switchover, as described in
Setting Reconnection Failure Parameters.