Creating Administered Objects

The JMS provider that you select should provide you with the tools to create and configure administered objects in a JNDI namespace. For most JMS providers, Integration Server cannot be used to create and configure administered objects. For more information about working with administered objects, refer to the product documentation for your chosen JMS provider.

However, Integration Server can create administered objects in the JNDI namespace when Universal Messaging is the JMS provider and the JNDI provider. Integration Server creates the administered object automatically when the lookup for the object fails. For example:

If a JMS connection alias attempts to connect to Universal Messaging using a connection factory that does not exist, Integration Server creates the connection factory and adds it to the JNDI namespace on Universal Messaging. Integration Server copies the connection URL from the JNDI settings.

If a pub.jms* service specifies a topic or queue as the message destination and the destination does not exist, Integration Server creates the topic or queue on Universal Messaging and then adds it to the JNDI namespace.

If a JMS trigger subscribes to a topic or queue that does not exist, Integration Server creates the topic or queue on Universal Messaging and then adds it to the JNDI namespace.

Whether or not Integration Server creates a missing administered object automatically is configured per JMS connection alias using the Create Administered Objects On Demand check box.

If you configure a JMS connection alias to create destinations and connection factories on demand, you do not need to use each time you want to create a connection factory or destination. Nor do you need to use Designer to create a destination from which a JMS trigger can retrieve messages. Using Integration Server to create administered objects on demand provides convenience and possible time savings during the development cycle.

For example, suppose that you receive an Integration Server package that contains JMS triggers and services that publish JMS messages. Further suppose that your Integration Server contains JMS connection aliases with the same names as the JMS connection aliases used by the services and triggers inn the package, the JMS connection aliases are configured to create administered objects on demand, and your Integration Server has a JNDI alias points to a running Universal Messaging server. When you start the JMS connection aliases, Integration Server creates any missing connection factories. As you use the sending services and JMS triggers in the package, Integration Server creates any missing destinations needed by the services and triggers.

To create the administered objects on demand, the JNDI provider must be the Universal Messaging JNDI provider and the JMS provider must be Universal Messaging. This because Integration Server uses the URL in the JNDI provider alias to create the objects in the JNDI namespace and on Universal Messaging.

Many JNDI providers, including the Universal Messaging JNDI provider, handle connection factory names and destination names in a case sensitive way. That is, “myFactory” and MYFactory” would be two different objects.

Integration Server provides the ability to create the objects only. Integration Server cannot update or delete the objects that it adds.

When Integration Server creates a connection factory specified in a JMS connection alias with a transaction type of XA_TRANSACTION, Integration Server creates an XAConnectionFactory (javax.jms.XAConnectionFactory).

Note: For a JMS connection alias with a transaction type of LOCAL_TRANSACTION, Integration Server creates a regular connection factory (javax.jms.ConnectionFactory).

If a connection factory exists but does not match the transaction type used by the JMS connection alias, Integration Server does not create a new connection factory. For example, suppose the JMS connection alias specifies a transaction type of XA_Transaction and a Connection Factory Lookup Name of “myConnectionFactory”. Additionally, suppose that a javax.jms.ConnectionFactory object named “myConnectionFactory” already exists in the JNDI namespace. When Integration Server starts the JMS connection alias and looks up the connection factory in the JNDI namepsace, Integration Server finds the existing “myConnectionFactory” javax.jms.ConnectionFactory object and does not delete and recreate the object to be a javax.jms.XAConnectionFactory.

Integration Server will not automatically create a connection factory that uses the Horizontal Scalability feature offered by Universal Messaging. If you want a JMS connection alias to use a connection factory that leverages the functionality available in the Horizontal Scalability feature, you must create the connection factory in Universal Messaging.

Integration Server simply creates the administered object if the object does not exist when Integration Server looks it up. If the name of the administered object is not specified correctly, adding objects on demand could result in the creation of unwanted administered objects. For example, if the Create Administered Objects On Demand check box is selected for a JMS connection alias, and that alias is used in pub.jms:send service that specifies “myQueue” as the destination, an instance of thepub.jms:createConsumer service that specifies “my_queue”, and a JMS trigger that specifies “MyQueue” as the destination, Integration Server creates three unique destinations in the JNDI namespace.

Note: Software AG recommends against using this feature in a production environment. That is, leave the Create Administered Objects On Demand (Universal Messaging check box cleared for a JMS connection alias on an Integration Server running in production.