System Administrator's Guide for Java Message Servicesbaansupport.com/docs/erpln/U9050BUS.pdftransport. Infor Integration employs the JMS Point-to-Point model for the request/reply

Infor Integration 6.2

System Administrator's Guide for Java Message Services

Copyright © 2007 Infor Global Technology Solutions GmbH and/or its affiliates and subsidiaries All rights reserved. The word and design marks set forth herein are trademarks and/or registered trademarks of Infor Global Solutions Technology GmbH and/or its affiliates and subsidiaries. All rights reserved. All other trademarks listed herein are the property of their respective owners.

Important Notices The material contained in this publication (including any supplementary information) constitutes and contains confidential and proprietary information of Infor Global Solutions.

By gaining access to the attached, you acknowledge and agree that the material (including any modification, translation or adaptation of the material) and all copyright, trade secrets and all other right, title and interest therein, are the sole property of Infor Global Solutions and that you shall not gain right, title or interest in the material (including any modification, translation or adaptation of the material) by virtue of your review thereof other than the non-exclusive right to use the material solely in connection with and the furtherance of your license and use of software made available to your company from Infor Global Solutions pursuant to a separate agreement (“Purpose”).

In addition, by accessing the enclosed material, you acknowledge and agree that you are required to maintain such material in strict confidence and that your use of such material is limited to the Purpose described above.

Although Infor Global Solutions has taken due care to ensure that the material included in this publication is accurate and complete, Infor Global Solutions cannot warrant that the information contained in this publication is complete, does not contain typographical or other errors, or will meet your specific requirements. As such, Infor Global Solutions does not assume and hereby disclaims all liability, consequential or otherwise, for any loss or damage to any person or entity which is caused by or relates to errors or omissions in this publication (including any supplementary information), whether such errors or omissions result from negligence, accident or any other cause.

Trademark Acknowledgements

All other company, product, trade or service names referenced may be registered trademarks or trademarks of their respective owners.

Publication Information

Document code: U9050B US

Release: Infor Integration 6.2

Publication date: July 07

Table of Contents

Chapter 1 Introduction............................................................................................................. 1-1 Purpose and scope .................................................................................................................... 1-1 Intended audience...................................................................................................................... 1-2 Overview JMS............................................................................................................................ 1-2 Definitions, acronyms, and abbreviations................................................................................... 1-3

Chapter 2 JMS Architecture .................................................................................................... 2-1 Java Naming and Directory Interface......................................................................................... 2-1 Composition of a complete JMS application .............................................................................. 2-3 Point-to-Point Model................................................................................................................... 2-4

Chapter 3 Configuration of messaging system ..................................................................... 3-1 Overview .................................................................................................................................... 3-1 To configure WebSphere MQ .................................................................................................... 3-2

To configure the JMSAdmin tool .......................................................................................... 3-3 Environment variables ......................................................................................................... 3-4 To create default Administered JMS Objects ....................................................................... 3-4 To monitor Administered JMS Objects................................................................................. 3-6 To create Administered JMS Objects manually ................................................................... 3-7

Chapter 4 Adapter configuration for JMS .............................................................................. 4-1 Basic settings for JMS................................................................................................................ 4-1 Bus Component configuration for JMS....................................................................................... 4-2 Message transport ..................................................................................................................... 4-3 Queues ...................................................................................................................................... 4-5

Message queues.................................................................................................................. 4-6

ii | Table of Contents

Deadletter queues................................................................................................................ 4-8 Defaults................................................................................................................................ 4-8

Connection to the JMS provider................................................................................................. 4-9 Defaults.............................................................................................................................. 4-10

Naming directory ...................................................................................................................... 4-11 Default LDAP directory ...................................................................................................... 4-11 Default non-LDAP directory ............................................................................................... 4-13

Minimal configuration ............................................................................................................... 4-13

Chapter 5 Advanced configuration......................................................................................... 5-1 Directory and namespace references ........................................................................................ 5-1

Provider URL and Initial Context Factory............................................................................. 5-2 To configure a Bus Component for a namespace................................................................ 5-3

Anonymous clients ..................................................................................................................... 5-4 Miscellaneous properties ........................................................................................................... 5-5

persistent ............................................................................................................................. 5-5 timeToLive ........................................................................................................................... 5-5

JMS properties of a Bus Component’s URI................................................................................ 5-5 Properties ............................................................................................................................ 5-6 Values and default values.................................................................................................... 5-7

Lookup order for configuration data ........................................................................................... 5-9

About this Guide

This document describes how you must configure Infor Integration for JMS to be able to use message-oriented middleware (MOM) as transport service for the request/reply communication in an Infor Integration connection.

This document guide only considers WebSphere MQ as middleware, which is the enterprise-messaging product of IBM. Other messaging products are expected to work as well, but WebSphere MQ is the only product that is tested. Other JMS providers must also work, but please, contact Infor OnePoint Support before implementing another JMS provider.

Java Message Service (JMS) is a Java API that enables users to access a variety of message-oriented middleware products, such as WebSphere MQ from IBM, SonicMQ from Progress Software, and WebLogic JMS from BEA. Through this API, applications based on the Java 2 Platform, Enterprise Edition (J2EE) can send messages to and receive messages from one of the queues of the messaging product. The messaging product manages the messages and the queues, and takes care of a reliable and secure message transport.

This document contains the following chapters:

Chapter 1, “Introduction,” introduces JMS and outlines how you can configure Bus Components, which represent the end points of an Infor Integration network, for messaging through JMS.

Chapter 2, “JMS architecture,” describes the architecture of a JMS application and describes how Infor Integration uses JMS for message transport. Infor Integration employs the JMS Point-to-Point model for the request/reply communication between a client and a server.

Chapter 3, “Configuration of messaging software,” explains in general terms how you must configure the enterprise messaging software as a JMS provider. The chapter cannot be specific, because the nature of the configuration depends on the used messaging software. However, the chapter presents some configuration examples for WebSphere MQ.

iv | Table of Contents

Chapter 4, “Adapter configuration for JMS,” describes how you must configure the Bus Components for clients and servers to access the enterprise messaging middleware through JMS.

Chapter 5, “Advanced configuration,” describes the advanced features of the Bus Components configuration to fine-tune the message transport.

Related documents

Infor Integration 6.2 – Installation Guide (U9018 US)

Infor Integration 6.2 – System Administrator's Guide for Generic Runtime Components (U9042 US)

Online documentation of Infor Integration

Send us your comments

We continually review and improve our documentation. Any remarks/requests for information concerning this document or topic are appreciated. Please e-mail your comments to [email protected].

In your e-mail, refer to the document code and title. More specific information will enable us to process feedback efficiently.

mailto:[email protected]?subject=Documentation

Table of Contents | v

1 Chapter 1 Introduction

Purpose and scope

This guide describes how you must configure Infor Integration to be able to use JMS message-oriented middleware as message transport tier for the request/reply communication in an Infor Integration connection. JMS stands for Java Message Service and is a message API that enables a Java program to access a wide range of messaging products. WebSphere MQ supports JMS from version 5.2 onwards.

Bus Components are the end nodes in an Infor Integration network, and consist of server and client computers. The general configuration of Infor Integration with the Central Configuration Console involves the set up of the Bus Components that employ JMS messages as transport device. You must specify for these components various message-related parameters, such as the name of the directory in which the administered JMS objects are kept, and the names of the administered JMS objects themselves.

In the case of Infor Integration, the administered objects comprise the Queue Connection Factory and the various Queues used for the message transport.

Note 1:

Although all messaging products with a JMS provider are expected to work properly with Infor Integration, the JMS provider of WebSphere MQ is the only provider that is tested and supported.

Note 2:

If you use MQSeries 5.1, the predecessor of WebSphere MQ, you must use the legacy Java message interface of IBM. The IBM interface consists of the MQSeries Java package com.ibm.mq, which contains the com.ibm.mq.jar file

1-2 | Introduction

and the mqji<language code>.properties file. For the Infor Integration configuration for MQSeries 5.1 or earlier, contact Infor OnePoint Support from help at http://onepoint.infor.com

Note 3:

This guide uses the terms Client Adapter and Server Adapter.

The term Client Adapter refers to the client runtime component of Infor Integration that receives a request from the client application, forwards this request as a Bus Document to the involved Bus Component, and receives the reply.

The term Server Adapter refers to the server runtime component of Infor Integration that receives the Bus Document with the client's request, handles the contained XML, invokes the server application and returns a Bus Document to the client with the server's reply.

Intended audience

This document is intended for application or system administrators who install, configure, and maintain Infor Integration software.

Overview JMS

Java Message Service (JMS) is a Java API that enables you to access a variety of Message Oriented Middleware products (MOM). The JMS provider implements JMS for a specific MOM and JMS providers are currently available for a wide range of message products, such as the following:

WebSphere MQ (MQSeries) from IBM

SonicMQ from Progress Software

WebLogic JMS from BEA

SmartSockets from Talarian

FioranoMQ from Fiorano

IBus MessageServer from SoftWired

This document only considers WebSphere MQ.

http://onepoint.infor.com/

Introduction | 1-3

Through the JMS API, applications based on the Java 2 Platform, Enterprise Edition (J2EE) can send messages to and receive messages from one of the queues of a supported MOM.

The MOM manages the messages and the queues, and takes care of a reliable and secure message transport. In the case of Infor Integration, the generic Infor Integration core represents the Java application that communicates with the MOM through the JMS interface.

The configuration data of the message queues and the related components are kept in a naming directory, which the user can access through the Java Naming and Directory Interface (JNDI). The JNDI service provider can be a LDAP-compliant Directory Service, another type of naming or directory service, or just a flat data file. Which type of data store is used will partly be determined by the MOM and partly by the company’s network configuration. A MOM-provider, for example, can supply a proprietary JNDI implementation, and a company can have an existing LDAP server that the company wants to leverage. Infor Integration accesses this naming directory to retrieve the required data and the message queues, such as the name of a queue and the name of the connection factory used to connect to a queue.

Definitions, acronyms, and abbreviations

Abreviation Description API Application Programming Interface: A set of functions

that can be called by other applications.

BOI Business Object Interface.

Bus Component A logical endpoint in a Infor Integration network, such as servers and named clients. Bus Components can be configured for certain connection points, pooling policies and activation services in the Central Configuration Console (CCC) of Infor Integration.

Business Object Interface

Business Object Interface (BOI) is a standard methodology to connect Infor Integration objects with other applications. BOI makes data and functionality on a server available to a client. On the client side, the BOI consists of a BOI proxy, which forms a substitute for data and functionality of one or more business objects on the server (BOI implementation).

Client Adapter The client runtime component of Infor Integration that receives a request from the client application, forwards this request as an XML message (Bus Document) to the involved Bus Component, and receives the reply from the back end.

1-4 | Introduction

Context (JNDI) A set of bindings with distinct atomic names, which is associated with a specific naming convention. A context provides a lookup operation that returns an object, and may provide operations such as for binding names.

Directory Service A network service that defines and manages resources (or other data) on a network and makes them accessible to users and applications. For Infor Integration, a Directory Service is used to centrally store the Bus Components and the associated configuration data for Infor Integration.

J2EE Java 2 Platform, Enterprise Edition.

J2SE Java 2 Platform, Standard Edition (successor to JDK), including the JVM for Java version 1.2.2 and later.

JMS Java Message Service JND Java Naming Directory

JNDI Java Naming and Directory Interface

LDAP Lightweight Directory Access Protocol, a set of open industry protocols for accessing a Directory Service.

LDAP Directory Service

A Directory Service that complies with the LDAP protocol. See also LDAP and Directory Service.

Message Asynchronous requests, reports, or events that are consumed by client applications. These messages contain information required to coordinate these applications. A message has a header to which additional fields can be added and a body. The message header specifies standard fields and optional properties. The message body contains the data that is being transmitted.

Message Queue An intermediary holding place for messages created to facilitate the management of asynchronous exchange of messages across a (distributed) network. The various queues reflect the status of the message, such as Incoming, Outgoing, or Failed.

MOM Message Oriented Middleware

MQ Message Queue

name space (JNDI) The set of all names in a naming system.

naming system (JNDI) A connected set of name-object bindings of the same type that has the same naming convention and provides the same set of operations with identical semantics.

Server Adapter The server runtime component of Infor Integration that

Introduction | 1-5

receives a Bus Document with a request from a client, handles the contained XML, invokes the server application and returns a Bus Document to the client that contains the server's reply.

Infor Integration Core The generic runtime core of the Infor Integration software that links enterprise applications that use Connectors and Adapters. The Infor Integration Core converts low-level syntax and complex data models into Business Objects. These Business Objects are exchanged between applications using Infor-specific XML messages called Bus Documents.

2 Chapter 2 JMS Architecture

Java Message Service (JMS) provides a common way for Java programs on the Java 2, Enterprise Edition (J2EE) platform to send and receive messages of an enterprise messaging system. JMS provides a set of interfaces (objects) and associated semantics that define how a Java program accesses the facilities of a messaging product. This type of Java program is called a JMS client. In the context of this document, the JMS clients are the Client and Server Adapters in the Infor Integration network that use JMS to transport messages with requests and replies.

The JMS provider implements JMS for a particular enterprise messaging product. Each messaging system, therefore, has a unique JMS provider that is specific to that particular system. JMS clients use the message implementations of the JMS provider of the applied messaging system.

Note:

Enterprise messaging systems are often also referred to as Message Oriented Middleware (MOM).

Java Naming and Directory Interface

Java Naming and Directory Interface (JNDI) is an API that provides directory and naming functionality to Java applications, which is independent of any specific directory service implementation. As a result, you can access a variety of directories in a common way.

JMS stores the configuration parameters of the administered objects in a repository that can be accessed trough the JNDI directory interface or the JNDI naming interface. The repository can be specific to the messaging product, or can be an external repository, such as a file system or an LDAP

2-2 | JMS Architecture

directory. Enterprise messaging systems and JMS clients access the directory through the Java Naming and Directory Interface (JNDI).

Administered objects refer to objects of which the properties are defined, stored, and maintained (administered) in the JNDI namespace, using the messaging system. JMS administrators use provider-specific facilities to create and configure these objects. JMS clients use this namespace to look up the object properties. The administered properties involve various types of configuration parameters that are specific to the messaging system, such as queue locations, authorization data, encryption parameters, and the error handling settings.

The messaging system and the JMS clients must know which type of naming system is used and where these clients can find this system. To indicate which naming system to use, you can specify system properties java.naming.factory.initial and java.naming.provider.url. The former provides the factory class that creates the initial context, which represents the starting point of the namespace, and the latter provides the name and address of the naming service.

To connect to a naming service, you start with an InitialContext that points to the root of the namespace you use. You create an initial context object with the following constructor methods:

public InitialContext()

or

public InitialContext(Hashtable environment)

The latter constructor creates an initial context, using the environment supplied in the specified hash table. Environment property java.naming.provider.url provides the initial context with the name and address of the naming service, whereas the environment property java.naming.factory.initial specifies the class name of the initial context factory.

If no arguments are passed to the constructor, the constructor uses the system property java.naming.factory.initial, which contains the class name of the initial context factory.

The InitialContext constructor attempts to create the initial context specified therein. The environment of the initial context is then inherited by contexts that are derived from the context.

All naming operations are relative to a context. The initial context implements the Context interface and provides the starting point for resolution of names. The Context interface is the principal interface of the JNDI API, which not

JMS Architecture | 2-3

only specifies a naming context, but also defines basic operations such as adding a name-to-object binding, creating subcontexts, or looking up an object bound to a specified name.

For more information on the InitialContext interface and the related environment properties, refer to the Java J2SE API Reference: http://java.sun.com/j2se/1.4.2/docs/api/index.html

Composition of a complete JMS application

The previous sections in this chapter discussed JMS clients, JMS providers, and JMS administered objects. This section summarizes the building blocks of a full JMS application.

A JMS application is composed of the following components:

JMS Clients The Java programs that send and receive messages, using the JMS API. In the case of Infor Integration, the JMS clients are the Server Adapters and Client Adapters in the Infor Integration network that has been configured for JMS message transport.

Non-JMS Clients The programs that use the native client API of the messaging system instead of the JMS API.

Messages Messages defined by the application and used to communicate information between JMS clients.

JMS Provider The messaging system that has been configured to support JMS. The system also possesses functionality to administer and manage messages and message queues.

2-4 | JMS Architecture

Administered Objects Message-related objects that are configured and maintained in the messaging system to be used by the JMS clients. The administered objects are stored in a JNDI namespace and accessed through the JNDI API.

Point-to-Point Model

To realize the request/reply communication between clients and servers, Infor Integration uses the JMS Point-to-Point model. This model is based on the concept of dedicated message queues. A JMS client sends messages to, and retrieves messages from, particular queues that are assigned to this client. Each client has therefore, essentially predefined queues to place or receive messages.

The following JMS objects play a key role in the JMS Point-to-Point model:

JMS Point-to-Point objects Description

QueueConnectionFactory An administered object a client uses to create a connection. The object encapsulates a set of administrator- defined connection configuration parameters.

QueueConnection An active connection to a JMS Provider.

QueueSession A single-threaded context for sending and receiving messages.

QueueSender An object created by a QueueSession that is used to send messages to a destination (a queue).

QueueReceiver An object created by a QueueSession that is used to receive messages sent to a destination (a queue).

Queue An administered object that encapsulates the identity of a message destination.

JMS Architecture | 2-5

The following figure depicts how you use the JMS Point-to-Point objects to realize the message transport between various JMS clients:

The connection factories and queues are the administered objects of the Point-to-Point model. As a result, you must define, store, and maintain these objects in the JNDI directory, using the message system. How you must do this is specific to the messaging system you use. Chapter 3, “Configuration of messaging system,” outlines in general terms how you can accomplish this and also provides an example of how to define a connection factory and queues using IBM’s WebSphere MQ.

You must also inform the JMS clients, in our case the Server and Client Adapters, about the names of the administered objects. The Adapters require this information to be able to look up these objects in the directory and then use the objects’ properties. To provide the Adapters with the names of the administered objects, you must include the names in the URI of a Bus Component’s connection. For more information on this subject, refer to Chapter 4, “Adapter Configuration for JMS.”

The Adapters internally handle the use of the JMS Point-to-Point domain to realize the message transport between clients and servers. However, you will not encounter this issue, therefore, you can disregard this point.

3 Chapter 3 Configuration of messaging system

Overview

The appropriate method to implement JMS support in an enterprise-messaging product includes the following steps:

1 Configure the messaging product as a JMS provider. The JMS provider implements JMS for a messaging product and handles the communication between the JMS API and the particular messaging product.

2 Define the connection factories and the queues in the Java Naming and Directory Interface (JNDI) namespace. The J2EE applications that send and receive messages through JMS (the JMS Clients, in our case the Client and Server Adapters) use these definitions.

The following figure shows the implementation of a JMS provider that is specific to the messaging system and the configuration of a JNDI naming service that contains the JMS administered objects of that provider. The JNDI naming service you use can be a directory specific to the messaging system, or some other naming service, such as a file system or an LDAP directory.

3-2 | Configuration of messaging system

The following section provides an example of how you configure MQ JMS support in the WebSphere J2EE environment.

Note:

You can use essentially any messaging system for data transport between Adapters, as long as these messaging systems support JMS, which means that a JMS provider is available for these systems. However, the only messaging system tested by Infor Integration at the moment is WebSphere MQ of IBM. Contact Infor OnePoint Support before you use other JMS providers.

To configure WebSphere MQ

This section provides an example of how you must configure WebSphere MQ to implement JMS support, on a Windows platform. In the example, the administered JMS objects are defined and stored in Sun’s LDAP-compliant naming directory (Sun ONE Directory Service). The configuration mainly consists of the set up of the JMSAdmin tool of WebSphere MQ and the application of this tool for administering JMS objects in the naming directory. For advanced configuration issues, refer to the WebSphere MQ documentation.

First, you must have installed the following components of WebSphere MQ:

Configuration of messaging system | 3-3

WebSphere MQ Server The software to create and run queue managers, and to handle the actual messaging.

WebSphere MQ Client The software to run a WebSphere MQ Client.

Java Messaging (including JMS support) The files required for messaging using Java, including IBM’s MQ classes for Java and the JMS classes.

Sun JRE Sun’s Java Runtime Environment (JRE), which is required to run any of the WebSphere configuration tools.

After you install these components, you must make various settings to run and configure WebSphere MQ successfully and deploy the JMS objects in LDAP.

To configure the JMSAdmin tool

The Java Message Service Administration (JMSAdmin) tool is a WebSphere tool to configure the JMS objects in a naming directory. To start the tool, you can run the Jmsadmin.bat file, which is present in the Java\bin subdirectory of the install directory of WebSphere MQ, which is usually C:\Program Files\IBM\WebSphere MQ. The following configuration example assumes that the JMS objects are kept in the LDAP-compliant Sun ONE directory.

To connect to the directory service for administering objects, this executable file uses the settings defined in a configuration file called JMSAdmin.config. This file resides in the same directory and represents the default configuration file for the WebSphere MQ Classes for Java Message Service Administration Tool. You must first configure this file before you can run the JMSAdmin tool.


The JMSAdmin.config file is extensively documented in the WebSphere MQ documentation. The following two properties are most relevant:

INITIAL_CONTEXT_FACTORY=com.sun.jndi.ldap.LdapCtxFactory:

Assuming you use Sun ONE Directory Server, you must set the Initial Context Factory property as shown here. Each JNDI service provider has a unique initial context factory, therefore, be sure to consult the respective service provider documentation to find what you must specify for this property.

PROVIDER_URL=ldap://ldap.myorg.com/o=MyOrg

The Provider URL contains the location of the JNDI provider, which consists of the name of the computer on which the LDAP server resides, and the root of the used namespace (initial naming context). In this example, ldap.myorg.com is the name of the computer and o=MyOrg is the namespace’s root.

You can change the other properties in this file for advanced configuration; however, for a basic configuration these properties can remain unchanged.

Environment variables

To run the JMSAdmin tool successfully, you must set the following environment variables:

MQ_ROOT_DIR=C:\Program Files\IBM\WebSphere MQ

MQ_JAVA_INSTALL_PATH=%MQ_ROOT_DIR%\java

MQ_JAVA_LIB=%MQ_JAVA_INSTALL_PATH%\lib

You must also add the following references to the classpath. Note that you must first remove all references to the old MQ Series based Jar files (version 5.1 or earlier) that were used for Adapter Suite 2.4 or earlier from the Classpath, if these files are still present.

Classpath="%MQ_JAVA_LIB%\com.ibm.mq.jar;%MQ_JAVA_LIB%\connector.jar;%MQ_JAVA_LIB%;%MQ_JAVA_LIB%\jms.jar;%MQ_JAVA_LIB%\com.ibm.mqjms.jar;%MQ_JAVA_LIB%\jndi.jar;%MQ_JAVA_LIB%\ldap.jar;%Classpath%"

To create default Administered JMS Objects

After you make the settings described previously, you can add the administered JMS objects to the LDAP directory server in the following two ways:


1 Create administered objects manually. To create the administered objects manually, you can use MQ Series commands interactively using the JMSAdmin tool. The following sections describe this option in detail.

2 Create administered objects using IVTSetup. Alternatively, you can use a file called IVTSetup.bat, which is located in the same directory as the JMSAdmin tool to create the administered objects automatically.

You use the IVTSetup.bat file to create the following default objects:

Queue Connection Factory

Queue

Topic Connection Factory

Topic

Afterwards, to query and modify these objects, you can use the JMS Admin tool, as described in the following sections.

If you run the IVTSetup.bat, this results in the following output:

In case of any errors, validate the settings of the environment variables, as discussed previously. If the ‘Unable to bind object’ error occurs, this indicates that the objects being created are already present in the naming directory.

In this case, proceed to the following section, “To monitor JMS Administered Objects.”

Note:

From the perspective of Infor Integration, you only need the Queue Connection Factory and the Queue objects, because Infor Integration currently does not support the JMS Publish-Subscribe model, in which the Topic Connection Factory and Topic objects are used.


To monitor Administered JMS Objects

You can start the JMSAdmin tool with the Jmsadmin.bat file. If everything is successful, the following prompt appears:

If this prompt does not appear, an error probably occurred with the configuration of the JMSAdmin.config file or with the classpath settings.

From this prompt, you can run WebSphere MQ commands to create and display the JMS objects. To view the objects created with IVTSetup, you use for example the display ctx command:

The display ctx command shows all the objects that are administered in the naming context. In the previous command console, the last four entries are the objects that were created with IVTSetup, as indicated by the objects’ common name.


To create Administered JMS Objects manually

You can create and manage the Administered JMS objects manually with the JMSAdmin tool, which enables you to give the objects logical names suited to the involved business process.


To assign these names, you must issue the following WebSphere MQ commands from the InitCtx prompt:

Command Short form

Description

alter alt Alter one or more properties of an administered object. Example: alter q(myQ) expiry(1050)

define def Create and store an administered object, or create a new sub-context. Example: define qcf(myQcf)

define ctx(subContext)

display dis Display the properties of one or more administered objects, or the contents of the current context. Example: display q(*)

Display ctx

delete del Remove one or more administered objects from the namespace, or remove an empty sub-context. Example: delete q(myQ)

delete ctx(emptySubContext)

change chg Change the current naming context to enable the user to traverse the directory namespace anywhere below the initial context (root entry), pending security clearance. Example: change ctx(subContext)

copy cp Make a copy of an administered object and store the object under another name. Example: copy q(myQ) q(mySecondQ)

move mv Rename an administered object.

Example: move q(myQ) q(yourQ)

end Close the JMS administration tool

Example: end

Note:

For more detailed information about the commands, refer to the WebSphere® MQ Using Java guide of the WebSphere MQ information center, which is installed along with the WebSphere software.


To define and display objects

With the define command, you create of a Queue Connection Factory called ClientMQQCF, which means that a Queue Connection Factory reference is created and stored in the naming or directory service:

define qcf(ClientMQQCF)

Next, you use also the define command to create a Queue object called ClientMQQueue:

define q(ClientMQQueue)

Finally, you use the display command to check whether you created the objects successfully:

display ctx

The last two entries from the output, as shown in the following figure, display the manually created components.

To retrieve information about an object, you once again use the display command and specify the particular object. To find out information about Queue Connection Factory ClientMQQCF, you must issue the following command from the InitCtx prompt:

display qcf(ClientMQQCF)

The result of this command is shown in the following command console:


The command lists for the specified object all properties and their values.

To alter objects As you can see in the previous list, the QMANAGER property has no value, which implies the use of a default Queue Manager. You can, however, change the value for the QMANAGER or any other property with the Alter command in combination with the property name:

alter qcf(ClientMQQCF) QMANAGER(myQueueManager)

After this modification, to view the result, you can use the display command again:


Similarly, you can modify the properties of a Queue object and subsequently view the result, for example:

After you configure the required administered JMS objects, the JNDI setup is ready to be used for the JMS transport. The final step is to reference in the Bus Component’s URIs to these JMS objects to configure the Adapters for JMS. The following chapter, “Adapter configuration for JMS,” describes the procedure that you must use to configure Infor Integration for JMS.

4 Chapter 4 Adapter configuration for JMS

Basic settings for JMS

As described in Chapter 2, “JMS Architecture,” Infor Integration uses the Point-to-Point model of JMS to realize request/reply communication between Adapter clients and Adapter servers. To be able to use this model, you must provide the Adapter servers and clients with the following information:

The JNDI namespace containing the administered JMS objects (the queues and the connection factory). To define the naming service and the namespace, you must specify:

The name and address of the naming service, provided by JMS property java.naming.provider.url

The class name of the initial context factory, provided by JMS property java.naming.factory.initial

For more information about the JNDI namespace, refer to “Java Naming and Directory Interface,” in Chapter 2, “JMS architecture.”

The QueueConnectionFactory object used to create a connection to a JMS provider. The object contains various connection configuration parameters defined by the JMS administrator.

The Queue objects used for the message transport. A Queue object encapsulates a provider-specific queue name, and is the way in which a client specifies the identity of a queue to JMS API methods.

Note:

All examples of Infor Integration configuration for JMS assume an LDAP-compliant naming/directory service, which means that all references to JMS objects start with a cn= prefix, for example cn=myQueue. If, however, you

4-2 | Adapter configuration for JMS

apply another naming system, such as a file-based system, other naming rules prevail and you can probably leave out this prefix. The prefix may in fact even be illegal for some naming services.

Bus Component configuration for JMS

To pass the information about the naming directory, the connection factory, and the queues to the Infor Integration runtime components, you must include the information in the Uniform Resource Identifier (URI) of one of the Bus Component’s Connection Points.

The URI for JMS message transport has the following format:

jms://v1.0/#get[<properties>] put[<properties>]

The get section refers to the location where an Infor Integration component receives messages and, similarly, the put section refers to the location where an Infor Integration component puts messages. Both sections can include the following references:

Queue The name of the queue to put or get messages, encapsulated by a Queue object.

Connection The configuration of the connection to the JMS provider that owns that particular queue, encapsulated by a QueueConnectionFactory object.

Directory The JNDI namespace used for looking up the Queue and ConnectionFactory objects. The namespace is specified by the initial context factory, property java.naming.factory.initial, and the naming provider URL, property java.naming.factory.initial.

In addition, you can define a dead-letter queue, which is a queue to put messages that are not recognized by Infor Integration.

After an explanation of how Infor Integration transfers messages using JMS, this chapter further discusses how you include references to the queues and connections in the URI of the Bus Component.

How to configure various naming directories and anonymous clients in Infor Integration is discussed in the following chapter. This chapter also provides a complete overview of all JMS properties that you can use to configure a Bus Component.

Adapter configuration for JMS | 4-3

Note:

A Bus Component object represents an end node in an Infor Integration network, such as a named client or a server. The object encapsulates a set of configuration parameters required to connect to an Infor Integration client or Infor Integration server. For more information on the configuration of Bus Components, refer to the System Administrator's Guide for Generic Runtime Components and the Central Configuration Console online Help.

Message transport

After you configured Infor Integration for JMS support, you must specify the JNDI namespace and the JMS administered objects, so Infor Integration can use the Point-to-Point JMS provider to send a request and reply to messages between Infor Integration servers and Infor Integration clients.


The following figure shows how an Adapter client sends a request message to an Adapter server at runtime:

For each call from a client, the Bus Component of the server is known. When the Client Adapter dispatches a request message, the Adapter extracts the name of the destination queue from the URI of the server’s Bus Component and sends this name along with the message to the JMS provider. The JMS provider forwards the message to specified queue of the messaging system (MOM). The MOM then handles the message and can transfer the message to some other queue, for example, because transformation or rerouting is required.

After the MOM processes the request message, the message turns up in the queue where the Server Adapter expects the request. The server Adapter knows which queue this is, because the server’s Bus Component’s URI contains a reference to this queue. On arrival of a request, the JMS provider generates an event that triggers the Server Adapter to retrieve the message.


The following figure shows how a Server Adapter sends a reply message to a Client Adapter at runtime:

The transfer of the reply message is similar to that of a request message, but now the direction is the other way around. The Server Adapter knows which client to address, because the client’s Bus Component is sent along with the request.

To find out to which queue the message must be sent, the Server Adapter retrieves the name of this queue from the URI of the client’s Bus Component.

Next, the MOM processes the message again and delivers the message on the queue the Client Adapter expects the replies. The URI of the client’s Bus Components references this queue.

Queues

This section describes how to configure Adapter for the JMS Queues used for the message transport by including queue references in the Bus Component’s URI.

First, the queues are discussed that play a role in normal, successful message transport, and then the dead-letter queue is handled. Adapter uses


the latter queue to store messages that Adapter does not understand, for example, because the format of the message is not supported.

Message queues

The request/reply communication between an Adapter client and an Adapter server involves four queues:

The queue where the client puts a request (Q1)

The queue where the server gets the client’s request (Q2)

The queue where the server puts a reply (Q3)

The queue where the client gets the server’s reply (Q4)

The arrival of a message triggers an event upon which the client or server retrieves the message.

The following figure depicts how these put and get queues are used for the transport of request and reply messages.

The client sends a request to the queue Q1. The messaging system forwards the request to the queue from which the server gets all the requests (Q2). After processing the request, the server then sends a reply to the server’s queue for replies (Q3). The server knows which client to reply to, because the client’s Bus Component is sent along with the message. The messaging


system forwards the reply to the client’s queue for replies (Q4). Finally, the client retrieves the reply from this latter queue.

An obvious configuration of the messaging system is one in which the queue where the client puts a request coincides with the queue where the server gets this request, and in which the queue where the server puts a reply coincides the queue where the client gets this reply. In other words, a configuration that only uses two queues: one for the requests and one for the replies.

The previous figure also illustrates how the Bus Components reference the involved queues:

Q1 The name of the queue where the client puts a request is included in the put section of the URI of the server’s Bus Component

Q2 The name of the queue where the server gets the request of the client is included in the get section of the URI of the server’s Bus Component

Q3 The name of the queue where the server puts a reply is included in the put section of the URI of the client’s Bus Component

Q4 The name of the queue where the client gets the reply of the server is included in the get section of the URI of the client’s Bus Component

As a result, the URI of the client Bus Component will be as follows, if you reference all four queues and use the default connection factory and naming directory:

jms://v1.0/#get[queue="cn=Q4"] put[queue="cn=Q3"]

And for the server Bus Component:

jms://v1.0/#get[queue="cn=Q2"] put[queue="cn=Q1"]


This shorthand notation is for the queue references in the Bus Component’s URI. The longhand notation for the client Bus Component is, for example:

jms://v1.0/#get[queue={name= "cn=Q2"}] put[queue={name="cn=Q2"}]

The longhand notation enables you to fill in additional queue properties, which specify the JNDI namespace used to look up the queues. For more information, refer to “Naming directory,” in this chapter.

Deadletter queues

The Deadletter queue is used to put messages that are received by an Adapter, but with which this Adapter does not know what to do.

The reason why the Adapter might not know what to do with these messages can be because, for example, the messages do not conform to the syntax supported by Adapter, if the messages somehow got corrupted, or if the messages are unexpected at that address.

In addition to the queues used for a successful request/reply communication between Adapters, you can specify in the get section of a Bus Component’s URI which queue is used as a dead-letter queue for messages unrecognized by Adapter. In that case, the URI’s syntax for dead-letter queue D is in shorthand notation:

jms://v1.0/#get[queue="cn=myQueue", deadLetterQueue = "cn=D"]

Defaults

The default queue name in the get section of a Bus Component’s URI is temporary, without quotes, which is the reserved word for a temporary queue. A temporary queue is a queue that is created when a queue is required to get a message from. You can only specify a temporary queue in the get section of a Bus Component, because specifying a temporary queue in a put section would be pointless. You can put requests or replies in the temporary queue, but no application would know that it was expected to get the message from that temporary queue.

The queue name in the put section of a Bus Component’s URI defaults to the same queue as referenced in the get section.

Note:

A TemporaryQueue is a unique Queue object created for the duration of a QueueConnection. The TemporaryQueue is a system-defined queue that can only be deleted by the QueueConnection that created the queue.


Connection to the JMS provider

When an Adapter sends a message through JMS, this message must be delivered at a specific pre-defined queue, which a JMS Queue object references. To reach this queue, the Adapter must first create a connection to the JMS provider that manages this queue.

Usually, you only use one JMS provider. In this case, you do not have to be concerned about the connection, provided you previously created a QueueConnectionFactory object in the JNDI directory called cn = defaultQueueConnectionFactory, with no spaces. This object encapsulates all connection configuration properties required to connect to the JMS provider. And even if more JMS providers are used, Infor recommends that you create such an object for your default JMS provider, because it makes the configuration of an Adapter for JMS easier.

If you use more JMS providers or if you do not have a QueueConnectionFactory called defaultQueueConnectionFactory, you must provide the Adapter with the information that is required to connect to the proper JMS provider. This connection configuration data is encapsulated by one of the QueueConnectionFactory objects stored in the JNDI namespace. You can pass on this data to an Adapter by including the name of a QueueConnectionFactory object in the URI of a Bus Component.

For each message transport, Adapter must find out which connection to use. When you send a message, an Adapter consults for connection data the Bus Component at the other side of the transport, and when you receive a message an Adapter consults its own Bus Component. This implies that:

When a Client Adapter sends a request, this Adapter looks in the put section of the Bus Component of the server

When a Server Adapter sends a reply, this Adapter looks in the put section of the Bus Component of the client

When a Client Adapter receives a reply, this Adapter looks in the get section of its own Bus Component

When a Server Adapter receives a request, this Adapter looks in the get section of its own Bus Component

This behavior of Adapter is similar to that with respect to queue references:


Considering four different connections A, C, D, and F to queues Q1, Q2, Q3, and Q4, respectively, as shown in the previous figure, QueueConnectionFactory objects in the URI of the client Bus Component are referenced as follows:

jms://v1.0/#get[queue="cn=Q4", queueConnectionFactory = "cn=F"] put[queue="cn=Q3", queueConnectionFactory = "cn=D"]

The URI of the server Bus Component references to QueueConnectionFactory objects in the following way:

jms://v1.0/#get[queue="cn=Q2", queueConnectionFactory = "cn=C"] put[queue="cn=Q1", queueConnectionFactory = "cn=A"]

Defaults

The default name of the QueueConnectionFactory object in the get section of a Bus Component’s URI is defaultConnectionFactory. If this object does not exist in the used namespace and the name of the QueueConnectionFactory object is omitted in the URI, an error occurs. Adapter then does not know which connection to create to reach a particular queue.

The default name of the QueueConnectionFactory object in the put section of a Bus Component’s URI is the one specified in the get section of the same URI.


Naming directory

Generally, for an Infor Integration connection, you use only one namespace of a particular naming directory to store, maintain, and retrieve administered objects, such as queues and connection factories. If that is the case, you are recommended to define this namespace as your default namespace, so you no longer must be concerned about specifying a namespace for each reference to an administered object in your Bus Component configuration.

The following sections describe how you define a namespace in a naming directory as your default namespace. The section “Directory and namespace references” in Chapter 5, “Advanced configuration,” describes how to specify a directory and a namespace in the URI of a Bus Component.

Default LDAP directory

If you use an LDAP-compliant directory to store the administered objects, as default directory Adapter expects the Infor Integration LDAP directory, which is the Configuration Directory specified in owconfig.properties that is also applied to store Bus Components and other configuration data. You can view the URL of this directory with the graphical Support Information tool of Infor Integrations, or the Central Configuration Console, and you can change the directory’s URL with the DirectoryURLEditor commandline tool. For more information, refer to the System Administrator's Guide for Generic Runtime Components and to the Central Configuration Console online Help.

In addition, Adapter requires as default namespace a cn=jms node in the Infor Integration LDAP directory, which must be a sibling of the Central Configuration Console node (cn= configurations), both of which are children of the root node of Infor Integration’s namespace, for example, o=mycompany.com, which is the root entry of the Directory URL you specified in owconfig.properties.


The following figure shows where you must place the cn=jms node to make this node the default namespace for an Adapter when you use JMS.

Note:

If you use an LDAP Directory or namespace other than the Infor Integration default namespaces, you must refer to that directory or namespace in each Bus Component used for JMS message transport.


Default non-LDAP directory

If you use a naming service other than an LDAP directory, Adapter complies with the defaults of JMS. As a result, Java system properties set the default naming service and default namespace. The system property java.naming.provider.url specifies the URL of the naming service and determines the default namespace. System property java.naming.factory.initial indicates the factory class to implement the initial naming context (the root of the namespace), which includes all connection configuration data.

For more information on these system properties, refer to “Java Naming and Directory Interface,” in Chapter 2, “JMS Architecture.”

Minimal configuration

In a minimal configuration, you use the default namespace and the default JMS objects as much as possible. In that case, you use two queues: a named queue for the server Bus Component and a temporary queue for the client Bus Component.

You only must reference in the get section of the Server Bus Component’s URI to the named queue, because the temporary queue is the default queue and the queues of the get sections are taken as default when the queue references in the put section are omitted. As a consequence, the simplest URIs for server and clients Bus Component’s will have the following appearance:

URI of server Bus Component

jms://v1.0/#get[queue="cn=myQueue"]

URI of all client Bus Components

jms://v1.0/#

Note:

For more information on the used defaulting mechanism, refer to “Lookup order for configuration data” in Chapter 5, “Advanced configuration.”

5 Chapter 5 Advanced configuration

This chapter describes two, more advanced features of the configuration of Infor Integration for JMS:

The configuration of the namespace and directory used for the Queues and QueueConnectionFactories (the administered objects)

The configuration of ‘anonymous clients’, using temporary queues

This chapter further provides a complete overview of the syntax of a Bus Component’s URI used to configure Infor Integration for JMS, and finally presents the lookup order for the configuration data.

Directory and namespace references

The section “Naming directory” in the previous chapter discusses the default namespace and default directory to store and maintain the JMS administered objects. If you do not support this default naming service, you must refer to the used namespace and directory in the URI of each Bus Component involved in JMS message transport. To refer to the namespace, you must specify the values for the jndiProviderUrl property and the jndiInitialContextFactory property.

5-2 | Advanced configuration

Note:

If you use just one namespace and one directory, however, including only one specification of the naming context in the get sections of the Bus Components is sufficient. For more information, refer to “Lookup order for configuration data” in this chapter. The specifications in this get section are taken as default values for the other section of the Bus Component’s URI (the put section).

Provider URL and Initial Context Factory

The property jndiProviderUrl of the Bus Component’s URI represents JNDI property PROVIDER_URL and specifies the URL of the directory or naming service (the JNDI provider). This URL specifies the unique name of the initial naming context in the directory (the root of the namespace), which is used when you look up JMS objects. You use the value of the jndiProviderUrl to set the JNDI environment property PROVIDER_URL, which is applied to implement an initial naming context, as shown in the following example.

For an LDAP-compliant directory, the value of jndiProviderUrl shows the following format: ldap://<ldapServer>/<distinguishedName>,

for example ldap://myServer/cn=jms,o=MyOrg. If you use another type of directory, a URL format is used that is specific to that particular directory. The directory service determines the formats that the service supports. Most directory services specify a default value for the PROVIDER_URL property.

Property jndiInitialContextFactory corresponds to JNDI property INITIAL_CONTEXT_FACTORY and specifies the name of the context factory class used for the directory’s implementation. This class holds information about the initial naming context (the root of the namespace) of the administered objects. You use the value of the jndiInitialContextFactory to set the JNDI environment property INITIAL_CONTEXT_FACTORY. The following example provides additional details.

The following example shows how you configure the initial context implemented by a file-based naming system, com.sun.jndi.fscontext.FSContextFactory.

// Initialize environment with various properties

Hashtable env = new Hashtable();

env.put(Context.INITIAL_CONTEXT_FACTORY,

"com.sun.jndi.fscontext.FSContextFactory");

env.put(Context.PROVIDER_URL, "file:/");

// Call constructor

Advanced configuration | 5-3

Context ctx = new InitialContext(env);

The URL string in this case is a file URL that specifies the file directory root for the implementation.

If you use an LDAP-compliant directory, the value of jndiInitialContextFactory takes the following form: com.sun.jndi.ldap.LdapCtxFactory. For other directories, the standard JNDI behavior is adopted.

To configure a Bus Component for a namespace

A Bus Component’s URI with references to a namespace in an LDAP directory shows, for example, the following appearance:

jms://v1.0/#get[jndiProviderUrl="ldap://myServer/cn=jms, o=mycompany.com",

jndiInitialContextFactory= "com.sun.jndi.ldap.LdapCtxFactory"]

This URI specifies the directory and namespace for all administered objects in the get section of the Bus Component’s URI. You can, however, specify various namespaces for each administered object, for example:

jms://v1.0/#get[queue={name="myQueue", jndiInitialContextFactory="com.sun.jndi.fscontext.FSContextFactory", jndiProviderUrl="file:/"}, queueConnectionFactory={name="cn=myQcf", jndiInitialContextFactory="ldap://myServer/cn=jms, o=mycompany.com", jndiProviderUrl="com.sun.jndi.ldap.LdapCtxFactory"}]


Anonymous clients

In the case of anonymous clients, all clients use the same Bus Component and each use a separate temporary queue to receive replies from the server.

The procedure is as follows:

1 A client application initializes a Business Object Manager with a particular Bus Component of a server that has been configured for JMS.

2 The Client Adapter ‘sees’ that the server uses JMS message transport and subsequently looks in the client’s Bus Component to find out which queue must be used for receiving the replies of the server. The Client Adapter discovers that this queue is a temporary queue.

3 The Client Adapter creates an instance of the temporary queue, which will be used for receiving replies from the server. The exact properties of this temporary queue are defined in the JNDI naming directory.

4 The client application calls a server function and the Client Adapter sends a request message to the server using the queue that has been specified in the server’s Bus Component. The request message contains a reference to the temporary queue to which the server must send its reply message.

5 The server application replies to the call and the Server Adapter sends a reply message to the temporary queue specified in the request message. The Client Adapter retrieves the reply message from the temporary queue and forwards its content to the client application.

6 When the client application has finished calling the server, the application closes the connection with the server, using the Close method of the Manager. The Client Adapter then releases all resources and removes the temporary queue instance.

The temporary queue is only used for receiving reply messages. For receiving requests, a predefined queue must be available. After all, a client needs to know where the client must send requests.

The following example shows how you can configure a Client Bus Component to receive reply messages in a temporary queue by specifying a temporary queue in the get section of the Bus Component’s URI:

jms://v1.0/#get[queue=temporary, queueConnectionFactory="cn=getReply"]


Miscellaneous properties

persistent

You can include a persistent property in the put section of a Bus Component’s URI. By including this property, you make messages sent to the component persistent. Persistent messages are messages that are written to disk as soon as they arrive and that can, therefore, be recovered after a system failure.

By default, the persistent option is turned off. To enable the option, you must include the term ‘persistent’ in the URI, for example:

jms://v1.0/#put[queue="cn=myQueue", queueConnectionFactory="cn=myFactory", persistent]

Note:

The persistence is a standard property of a message queue that you can use the messaging middleware to set. For WebSphere MQ, for example, you can set the Default Persistence field to Persistent or Non-Persistent when you configure a queue.

timeToLive

The integer value for the timeToLive property of a Bus Component’s URI determines the lifetime of an outgoing message in milliseconds. This property corresponds to the parameter with the same name of the JMS method send and only applies to messages that are sent to a certain Bus Component. Therefore, you can only include the timeToLive property in the put section of a URI, for example:

jms://v1.0/#put[queue="cn=myQueue", queueConnectionFactory="cn=myFactory", timeToLive=200]

The default value for the timeToLive property is 0, which means that a message lives forever.

JMS properties of a Bus Component’s URI

This section provides a complete overview of the properties that you can use to configure a Bus Component’s URI for JMS. All properties are optional, and


except for the timeToLive property, all properties have strings values. The value for timeToLive is an integer.

If the value for a property is omitted, the default value is used.

Properties

Property Description

jndiContextFactory The name of the factory class for the initial naming context used to look up JMS objects. The value is used to set JNDI environment property INITIAL-CONTEXT_FACTORY.

jndiProviderUrl The URL of the JNDI directory that contains the naming context used to look up JMS objects. The value is used to set JNDI environment property PROVIDER_URL.

queueConnectionFactory (name)

The name of a queueConnectionFactory object. This object creates a connection to a queue.

queue (name) The name of a Queue object.

deadLetterQueue (name) The name of the deadLetterQueue object.

persistent Option to make messages persistent, which means that the messages are written to disk as soon as the messages arrive at a queue. In case of system failure, the message can be recovered when the system is started again.

timeToLive Time in milliseconds a message is kept in a queue before the message is deleted.


Values and default values

Property get section Default

jndiContextFactory For LDAP directories: com.sun.jndi.ldap. LdapCtxFactory, for other directories the default JNDI behavior.

jndiProviderUrl For LDAP directories: ldap://<ldapServer>/cn=jms, <directoryRoot>, for other directories the default JNDI behavior.

queueConnectionFactory.jndiContextFactory

The value of property jndiContextFactory.

queueConnectionFactory.jndiProviderUrl

The value of property jndiProviderUrl

queueConnectionFactory.name

Factory object defaultQueueConnectionFactory.

queue.jndiContextFactory The value of property jndiContextFactory.

queue.jndiProviderUrl The value of property jndiProviderUrl.

queue.name temporary (without quotes)

deadLetterQueue.jndiContextFactory

The value of property jndiContextFactory.

deadLetterQueue.jndiProviderUrl

The value of property jndiProviderUrl

deadLetterQueue.name Queue object deadLetterQueue.


Property put section Default

jndiContextFactory If set, the value of the same property in the get section, otherwise, the value of the same property in the local get section.

jndiProviderUrl If set, the value of the same property in the get section, otherwise, the value of the same property in the local get section.

queueConnectionFactory.jndiContextFactory

If set, the value of the same property in the get section, otherwise, the value of property jndiContextFactory of the put section.

queueConnectionFactory.jndiProviderUrl

If set, the value of the same property in the get section, otherwise, the value of property jndiProviderUrl of the put section.

queueConnectionFactory.name

If set, the value of the same property in the get section, otherwise, the value of the same property in the local get section.

queue.jndiContextFactory

If set, the value of the same property in the get section, otherwise, the value of property jndiContextFactory of the put section.

queue.jndiProviderUrl

If set, the value of the same property in the get section, otherwise, the value of property jndiProviderUrl of the put section.

queue.name

The value of the same property in the get section, if the get property has been set and is not temporary. If this get property is unset, an error occurs in all other cases.

persistent Not set.

timeToLive 0.


Lookup order for configuration data

The following figure illustrates a message transport between a client and a server using a JMS provider.

The client-server communication consists of four connections managed by Adapter: connections A, C, D, and F. The messaging system controls connections B and E.

For this situation, the following tables detail Adapter’s lookup order for the configuration data for JMS. In the table, S and C indicate the server and the client, and p and g denote the put section and the get section of the Bus Components URI; <defaults> specifies the default configuration properties. The lookup order is from left to right.

Connection Lookup order

Client gets reply (F) C-g, <defaults>

Client sends request (A)

S-p, S-g, C-g, <defaults>

Server gets request (C) S-g, <defaults>

Server sends reply (D) If ReplyTo is used:

<replyTo>, <serializedBus Component>, S-g, <defaults>

If ReplyTo is not used:

C-p, C-g, S-g, <defaults>
