Access external services with messaging systems


Access external services with messaging systems

Messaging uses a loosely-coupled style of interaction among applications. Messaging involves an intermediary called a messaging provider. In this section, we discuss the messaging concepts you should know. In the following sections, we list the messaging providers that are supported by IBM Integration Designer and the bindings that are used with these messaging providers.

This overview discusses these messaging concepts:

Asynchronous messaging does not communicate immediately like a synchronous method of communicating. Instead, applications send messages to the messaging provider. The messaging provider delivers the message to the target application, similar to the postal service. Like the postal service, the messaging provider offers the application levels of quality of service, which come at a price such as performance degradation. This quality of service guarantees that messages are delivered, there are no duplicates, that a message sequence is maintained, and so on. Sending and receiving applications do not need to know of each other's existence or the nature of the messages that each application understands. Each application is concerned with defining the format of the messages that it will use to communicate and establishing access to the services offered by the messaging provider. The messaging provider provides services to dynamically route and optionally transform the message so it can be understood by the receiving application.

Although messaging is only asynchronous, there is also synchronous messaging, which means that both applications are available simultaneously and communicate directly in a tightly coupled manner. Synchronous messaging can be used when the performance degradation added by introducing an intermediary is not justified or when guaranteed delivery is not as high a priority. Response time is often an important aspect of synchronous messaging. Synchronous messaging means that updates and changes to an application must be known to its messaging partner.

In enterprises, many applications need to interact with one another in support of a business. These applications change as the business itself changes. Therefore, loosely-coupled applications using a messaging provider is usually a key to getting disparate applications distributed across the enterprise exchanging and using data. Not surprisingly, asynchronous messaging plays a significant role in service-oriented architecture (SOA). The following messaging architecture diagram presents loosely-coupled business applications connected to a messaging provider such as IBM WebSphere MQ and exchanging messages in order to perform business functions. Each message has data that can be independent of the applications using it, such as a list of inventory items. Typically, they are self-contained and can be processed independently but messages can be ordered and processed sequentially.

In point-to-point messaging there is only one consumer. The application identifies the target destination of the message. The messaging provider delivers the message to the destination where the receiving application retrieves it. It is a one-to-one relationship. If the same message must be sent to several applications then the sending application must send it separately to each one. Point-to-point messaging is suitable to when an application communicates with another single application or few applications. For example, an application sends a message to a human resources application that updates an employee record.

In publish-subscribe messaging a topic defines a subject that is associated with messages. Applications interested in that subject subscribe to that topic. An application subscribing to a topic is a subscriber. An application that sends the messages for a topic is a publisher. The messaging provider matches the message's topic with the subscription list. Publish-subscribe messaging is generally a one-to-many relationship between publisher and subscriber though it is possible to have only one or even zero subscribers. Publish-subscribe messaging is suitable when data needs to be distributed to a varying number of applications, which can change at any time. Publish-subscribe messaging is often used with event-driven situations. For example, an application publishes stock prices to a set of subscribing financial applications.

A message producer is the term for the application sending a message to the message provider. The message can be delivered using either point-to-point or publish-subscribe messaging. Before sending, the messaging provider checks the quality of service. For example, a message could be marked persistent, meaning the message should be written to a storage mechanism, such as a database, until the message has been read. This ensures the message is not lost should the system fail due to a hardware failure, power failure, and so on. The higher the quality of service, the greater the performance degradation. Quality of service is determined by business needs. Some messages do not need to be stored, such as publishing the latest stock market prices. But a financial record must be stored. An application sending a message often expects a reply indicating the receiving application has completed a task.

A message consumer is the term for the application receiving the message from the messaging provider. Two modes describe how the messages are received. In the first mode, the messaging provider starts the application when the message arrives. In the second mode, the application polls the messaging provider for a message. A message consumer could be an application listening for events such as a news update. Once the message arrives, the message consumer processes it. If there are errors and the message consumer cannot process it, the message is sent again until message retrying expires. The number of retries is determined by the quality of service.

Message producers often communicate with message consumers using the one-way pattern. For example, a message producer could be keeping a consumer informed of current international currency rates, in which case there is no need to transmit information back to the producer.

Message producers and message consumers sometimes communicate using the request-reply pattern, which is a conversation between the two about a set of related messages. A request-reply pattern is similar to two one-way messages. With a request-reply pattern, an application is both a producer and a consumer. For example, an application as a requester sends a message requesting an order and another application as a responder sends a reply to the requester with a status of that order. From the requester's perspective, its application is sending a message to the responder and receiving a message from the responder. From the responder's perspective, its application is receiving a message from the requester and sending a message to the requester. When several requests are sent to the same responder, then correlation identifiers distinguish between the replies from the responder so that a specific reply matches a specific request.

How does an application connect to a messaging provider and use its services? A messaging provider does have APIs and one way to get to that API with a minimum of coding is to use a resource adapter. The resource adapter is an implementation that can communicate to an EIS system, including a messaging provider. Java™ Message Service (JMS) provides client Application Programming Interfaces (APIs) to interact with the messaging provider. The resource adapter can be the interactive link between application and messaging provider, both of which interact with the resource adapter.

A resource adapter allows a Java EE server to communicate to an EIS system. An adapter that is JCA 1.5 compliant and JMS 1.1 compliant provides JMS as a managed resource. Using such a resource adapter means good integration, allowing its lifecycle, quality of service and resources to be managed by an application server.

Use a resource adapter or using the JMS API directly are two ways to connect to a messaging provider. Another way is to use native calls to a messaging provider such as used by IBM WebSphere MQ. These calls are made using the Message Queue Interface (MQI). MQ JMS uses the JMS API (as opposed to MQI) to access WebSphere MQ. A key decision by developers is choosing the best strategy for a particular application. If you are working with native JMS applications then use JMS. If you are working with JMS applications that are using the MQ backbone then use MQ JMS. If you are working with native MQ applications then use MQI.

The portability versus performance tradeoff is another factor to consider. If portability is important, choose JMS. If performance is important, using WebSphere MQ with native calls might be the appropriate choice. MQ JMS provides some portability with some performance benefits over JMS. The choice of strategy decides what type of binding to select. These types of messaging bindings, all of which are available in IBM Integration Designer, are discussed in this section.


Mapping a message to an SCA interface

An import with a messaging binding such as JMS, MQ, MQ JMS or generic JMS that exchanges messages with an export with a messaging binding could be considered as messaging clients to each other. In order for your service component architecture (SCA) application to communicate with an existing JMS, MQ or MQ JMS messaging client, certain SCA artifacts need to be created.

This section describes how to create a business object and an interface that represents your messaging client application in an SCA manner. Imports, exports, and bindings are also discussed. SCA applications use imports with messaging bindings to send messages to messaging clients and use exports with messaging bindings to receive messages from messaging clients.

Make sure that a module that contains your service component architecture application exists and the message format used by the JMS, MQ, or MQ JMS client is known.

These SCA artifacts and their relationship to a JMS client are discussed in the following sections:


Business object

In order for your SCA application to communicate with an existing messaging client, have a business object that would represent the message used by the messaging client.

If the message used by the client is in XML format, the XML schema that defines it is used as your business object. If you have this schema, import it into your module. The imported XML schema then appears under Data in your module. If you do not have this schema, you can create a business object and add the appropriate attributes to it that will mirror the XML format used by the client.

If the message used by the client is not in XML format and there is no XML schema that defines it, create a business object and add the appropriate attributes to it so that it reflects logically the message format used by the JMS client. For example, if the message conforms to the Enterprise JavaBean (EJB) model, you create a business object and add appropriate attributes to the business object to represent the attributes of the EJB model.

JMS provides a message class that can have one of five body types containing the message in a different format. IBM Integration Designer supports this message class. To reduce the development time, IBM Integration Designer provides a feature in its dependency editor to generate appropriate business objects for each of these JMS body types.

To create the business object.

  1. Right-click Data in your module, and select New > Business Object from the menu.

  2. Specify an appropriate name for your business object and click Finish.

  3. Add the appropriate attributes to your business object to fully describe it, and save the object.

Data bindings, which are discussed later, handle the transformation of data passed in native format from a messaging system or EIS system to a Service Data Object (SDO) in a Service Component Architecture-based (SCA) application.


Interface

In order for your SCA application to communicate to an existing messaging client, you must have an interface that represents the input and output of the messaging client application; that is, the interface represents the interaction with the client.

The interface has business operations to describe the messaging client application operations. The operationstyle, such as document literal wrapped, document literal, or RPC, to be implemented must be decided. An operation can be one-way, sending a message and not expecting a response, or request-response, sending a message and expecting a returning message.

The type of the operation is the type of the business object that represents the message used by the messaging client. For example, in the case of employee information, an employeeRecord business object should be used or created. Based on the content of the employee information, it might cause an employee record to be created or an existing employee record to be updated or deleted. So on the interface, you could have three operations: createEmployeeRecord, updateEmployeeRecord, and deleteEmployeeRecord.

To create the interface.

  1. Right-click Interfaces in the navigation of your module, and select New > Interface from the menu.
  2. Specify an appropriate name for the interface and click Finish.

  3. Add the appropriate operations to your interface to fully describe the interaction with the messaging client, and save the interface.


Imports, exports, and bindings

A business object represents the message received and sent from the JMS, MQ, or MQ JMS messaging client, and an interface represents the interaction of the input and output of the messaging client. But how is the data transferred between the client and these SCA artifacts? Business objects and interfaces are found in a module, which is similar to a project container. Imports and exports define the external interfaces or access points of the module. In other words, the messaging client interacts with an SCA application's business objects and interfaces through imports and exports.

Imports identify services outside of a module that can be called from within the module. Exports allow components to listen to requests from external clients. An export allows an external event to be processed. When a message is put on a destination, the associated SCA export processes the event invoking the targeted SCA component. With respect to messaging, imports and exports work as a pair to send and receive messages. An import allows an internal event in the SCA application to be processed. When such a message is put on a destination queue, the associated messaging client processes the event. When a message is put on a destination queue, the associated SCA export processes the event invoking the targeted SCA component.

Binding information, which specifies the means of transporting the data from the modules, is required for an import or an export. Several messaging bindings, including JMS, MQ, and MQ JMS, are available.

The relationship of bindings, messages in the context of imports and exports, and types of operations in interfaces is shown in the following table.

The relationship of bindings and the types of operations in interfaces used in the context of how the client behaves

JMS, MQ, or MQ JMS bindings One-way operation in an interface Request-response operation in an interface
Import binding Client receives message Client receives and sends message
Export binding Client sends message Client sends and receives message

To create an import with a messaging binding.

  1. Open the assembly editor.

  2. From the import group on the palette, select an import and drag it on to the canvas. An import with no implementation and no interface is created.
  3. Right-click the import and select Add Interface from the menu.

  4. Add an interface with at least one operation.
  5. Generate the binding by right-clicking the import and, from the menu, select Generate Binding > Messaging Binding > <type_of_binding>.

To create an export with a messaging binding.

  1. Open the assembly editor.

  2. From the component group on the palette, select an export and drag it on to the canvas. An export with no implementation and no interface is created.
  3. Right-click the import and select Add Interface from the menu.

  4. Add an interface with at least one operation.
  5. Generate the binding by right-clicking the export and, from the menu, select Generate Binding > Messaging Binding > <type_of_binding>.



Related concepts:

Java Message Service (JMS)

WebSphere MQ Java Message Service (MQ JMS)

Generic JMS

WebSphere MQ (WMQ)


Related reference:

Recommendations when using messaging bindings

Language support in non-EIS bindings


Java Message Service (JMS)

JMS is a standard API for sending and receiving messages. It allows components based on the Java™ Platform, Enterprise Edition (Java EE) to create, send, receive, and read messages.

This section examines the JMS programming model. The section then shows how a JMS message maps to Service Component Architecture (SCA) artifacts; that is, how a message maps to a business object and how input and output from a JMS client maps to an interface's operations. Data bindings and an important function called the function selector are discussed. You are then led through the generation of a JMS import and export binding and presented with some standard applications that make use of the JMS binding.



Related concepts:

WebSphere MQ Java Message Service (MQ JMS)

Generic JMS

WebSphere MQ (WMQ)


Related reference:

Mapping a message to an SCA interface

Recommendations when using messaging bindings

Language support in non-EIS bindings


Java Message Service (JMS) programming model

The JMS programming model is discussed in this section.

JMS defines an API for accessing services from a messaging provider; that is, it is not a product itself. It is a set of interface classes that messaging provider vendors implement. Applications that use the JMS API can then communicate with the messaging provider the vendor supplies. The JMS API has become the industry standard interface for Java™ applications to create, send, receive and read messages using messaging providers that support the JMS API. The standard is associated with the Java EE platform. Java EE is a set of standards for a component-based way to develop, assemble and deploy enterprise applications. Java EE containers implement a standard runtime environment that provides quality of service items such as security, transaction support and thread pooling.

In the following diagram, the JMS provider implements the JMS API. It is the entity with which the JMS client interacts. The JMS client establishes a connection and a session through which the interaction takes place. The JMS client establishes the connection based on configuration information in the connection factory and identifies where a message is to be sent to or retrieved from based on the destination. Both the connection factory and destination objects are listed in the Java Naming and Directory Interface (JNDI) namespace. JNDI is the Java industry standard API for accessing naming and directory services. Since the connection factory and destination are administered objects by JNDI, it means the JMS client can connect to different JMS providers without changing JMS client code; that is, it creates portability. It also means that attributes which often can and do change dynamically such as the destination can be changed independent of the JMS client code.

JMS has two messaging domains: point-to-point and publish-subscribe, which are the common ways of distributing messages. Note that JMS lets an application send or receive messages in either domain. The following table shows the interfaces used by these domains.

In the following table, JNDI-administered interfaces are indicated by an asterisk.

Messaging Domain Interfaces

Common Point-to-Point Publish-Subscribe
ConnectionFactory * QueueConnectionFactory * TopicConnectionFactory *
Connection QueueConnection TopicConnection
Destination * Queue * Topic *
Session QueueSession TopicSession
MessageProducer QueueSender TopicPublisher
MessageConsumer QueueReceiver, QueueBrowser TopicSubscriber

The JMS application is written to use only references to interfaces. Vendor-specific information is encapsulated in implementations of the following JMS administered objects: QueueConnectionFactory, TopicConnectionFactory, Queue and Topic.

These JMS administered objects are built using a vendor-supplied administration tool and stored on a JNDI namespace. A JMS application can retrieve these objects from the namespace and use them without needing to know which vendor provided the implementation.

At run time, the JMS client retrieves the connection factory (ConnectionFactory object) from a JNDI namespace and uses it to create a connection. The connection creates a session, which, in turn, creates a message producer or message consumer or both. The session also creates messages, which are sent to or retrieved from a destination (retrieved from a JNDI namespace) using the message producer and message consumer.

A recommended book that discusses JMS and its relationship to WebSphere in detail is Enterprise Messaging Using JMS and IBM WebSphere by Kareem Yusuf.



JMS features

Several features of JMS bindings and how SCA artifacts work with them are discussed.

This section examines these JMS features in relation to SCA artifacts:


Callback destination

SCA services that access messages asynchronously require callback methods and correlation objects, which are explained in this section.

Any SCA service can be accessed in a synchronous or asynchronous manner, independent of whether the service itself is synchronous or asynchronous.

An SCA service interface is always defined in the synchronous form. Additional interfaces are created to support the asynchronous model. These interfaces pass a callback object with the asynchronous request. Once the called service finishes processing the request, it returns the results to the callback object. A correlation object, known as a ticket, is used to correlate the response with the original request.

Both the JMS import and export use a destination, the callback destination, to store callback information. This is an internal SCA JMS service mechanism used to support SCA asynchronous invocations, which has been exposed to allow performance customization.

When a JMS import is invoked in a synchronous manner, it will put the JMS message onto the send destination and store the callback information in the callback destination using the correlation scheme of the request JMS message. The JMS import then uses a Message Driven Bean (MDB) to listen for the reply message. When the reply message arrives, the MDB uses its correlation ID to retrieve the callback information. It then uses the callback information to invoke the callback object with the response.

A JMS export uses a MDB to listen on the receive destination. When a message is received it will dispatch the request to the SCA runtime and will store JMS response information in the callback destination using the ID of the ticket. When the callback is invoked it will retrieve the JMS response information from the callback destination using the ID of the ticket such as the 'send' destination, the correlation ID and its output data binding. Then the callback's response argument and the JMS response information is used to create the response JMS message and send it to the reply destination.


Fault handling

JMS fault handling is used to handle exceptions at run time.

You can configure your import and export bindings to handle faults ( business exceptions). A fault handler can be set up at three levels: you can associate a fault handler with a fault, with an operation, or with a binding. For import bindings, you can also set up a fault selector to determine whether a response is a fault and, if so, the name of the fault. See Handling faults in bindings for more information.

Several prepackaged fault selectors are available. See Prepackaged JMS and MQ fault selectors.


Quality of service

An attribute, asyncReliability, is available on a JMS export binding's performance attributes tab. This attribute specifies the reliability the SCA runtime uses during asynchronous invocation of the export's target component. When it is set to assured, delivery of the message is guaranteed. The message will be persisted if necessary. When the attribute is set to bestEffort, the delivery of the message may fail in the event of system failure. Message persistence requires a cost to performance. If your application does not need guaranteed message delivery you should set the attribute to bestEffort. The default value for this attribute is assured.


JMS header properties

JMS header properties can be set from the JMS import method binding. One special user property is TargetFunctionName. This property can be used in conjunction with the supplied default FunctionSelector, in a JMS export, to control how a message is mapped to a service method. JMS header properties can be dynamically accessed and set using an XSL transformation in a mediation flow. A mediation flow can take an incoming message header property and transform it using an XML map.


Correlation schemes

For request-response or two-way operations, the JMSCorrelationID of the response message must contain the request message's JMSMessageID. This JMSMessageID is used to retrieve the callback information, to return the response to the calling service. When an SCA JMS import is used to invoke a JMS client, the JMS client must take the JMSMessageID from the request message and set it into the JMSCorrelationID of the response message.



Work with JMS bindings

JMS bindings can be generated for imports and exports with either a one-way operation or request-response operation. All cases are discussed in this section.



Generating a JMS import binding

Generate a JMS import binding with either a one-way operation or request-response operation is shown in this section. Once generated, the binding properties are discussed.

Prerequisite: You should have a module.

If you intend to use the standard JMS message class with a body type containing the message then use the business objects provided for these body types (see Work with the simple JMS data bindings).

In this set of steps, you will learn how you could create a JMS binding for an import. A JMS binding is used when you want to access the WebSphere Default Messaging Provider.

  1. Open the assembly editor. Under Outbound Imports, select JMS and drag it to the assembly editor. Select an interface or create one.

    Alternately, select Import under Component on the palette and drag it on to the canvas. An import component with no implementation and no interface is created. Right-click the component, select Add Interface from the menu and add an interface describing your interaction with a JMS client. Generate the JMS binding by selecting the component and from the menu selecting Generate Binding > Messaging Binding > JMS Binding.

  2. The Configure JMS Import Service window box opens. The window is similar for both an interface with a one-way operation or a request-response operation. However, an interface with a request-response operation has an additional field for a receive destination.

    Select the messaging domain: Point-to-Point or Publish-Subscribe.

    Select to Configure new messaging provider resources (the default) or Use pre-configured messaging provider resources. If you choose pre-configured, then add the JNDI names for the connection factory and the send destination for a one-way operation, and send and receive destinations for a request-response operation.

    You should periodically check your binding configuration information at run time in the administrative console. In particular check the state of the endpoint. Under some conditions the endpoint may go into a paused state and restart it (see View or changing the state of an endpoint).

    If you specify JNDI names and then switch to specifying your own configuration properties both sets of values remain in memory until you close the editor. You are saved from reentering the values while you decide.

    In the Default data format field, select how the data will be serialized between the business object and the JMS message with a binding. To change the default, click Select beside the field to launch the Data Transformation Configuration window. Your selections are as follows:

    In the next section, to use the TargetFunctionName message header property to be used with module to module communication, select it. To use the default module to module fault handling, which is a SOAP transport, select it.

    A common way for specifying a userid and password is through using the Java EE Connector (J2C) authentication data entries. The entries are defined on the server. In the Security configuration section, select Specify a Java Authentication and Authorization Services (JAAS) alias security credential when server security is enabled, if it is used by your organization. Enter the Java EE Connector (J2C) authentication data entry.

    Click OK. The JMS binding is created and shown in the properties view when the Binding tab is selected.

  3. Selecting the Binding tab shows the adapter type and serialization type.

  4. Selecting the End-point configuration tab and Connection tab allows you to specify a JNDI lookup name. If a JNDI lookup name is specified then you are using a managed connection factory configured on the server, so the managed connection factory class and its properties will not be shown here. In addition, all sections except method bindings properties and authentication properties on the Security attributes tab will not be shown. In our case, a JNDI lookup name was not specified, so the managed connection factory will be created on the server using the properties specified here. The default messaging provider provides a domain-independent managed connection factory (conforming to the JMS 1.1 specification), which is selected by default.

    The Managed Connection Factory Properties section specifies the managed connection factory class and its properties such as the service bus name and quality of service with respect to persistence, in the case of the WebSphere default messaging provider resource adapter. The necessary fields are completed for you. Advanced indicates quality of service properties such as persistence properties and if this is a shared property.

  5. Expanding Admin Connection Properties provides connection pool properties and configuration properties if you would like custom names and values. If you had specified an JNDI name earlier, it is empty since the server is determining connection pooling values.

  6. Selecting the JMS Destinations tab lists the sending, receiving and callback properties. In the Send Destination Properties section, the type of destination and its properties are listed and can be changed. If you specify a JNDI name, this information is not available as it is configured on the server; that is, the destination specified on the server under this JNDI name will be used.

    If you specify nothing in the Queue Name or Topic Space field, a default value will be created. If you specify a queue name or a topic space, this value will remain even if you then clear the field. The only way to change the value is to specify a different value. A name is required because you initially generated a one-way or request-response operation, which requires a name for the destination.

  7. In the Receive Destination Properties section, the type of destination and its properties are listed and can be changed. If you specify a JNDI name, this information is not available as it is configured on the server.

    If you specify nothing in the queue name or topic space field, a default value will be created. If you specify a queue name or a topic space, this value will remain even if you then clear the field. The only way to change the value is to specify a different value. A name is required because you initially generated a request-response operation, which requires a name for the destination.

  8. In the Callback Destination Properties section, the callback destination type may be specified or a JNDI name where the same information is specified.

    The Response Connection tab allows you to specify properties on the response connection in the case of a request-response operation. You can specify an ActivationSpec class name, a listener type and a function selector.

  9. Selecting Method bindings shows the bound methods. By default, all methods are bound. However, some of these methods may not be needed for JMS usage. If so, clear the Bind check box under the Generic tab. You may also add a description of the method binding.

    The Data Serialization tab lets you specify the input and output serialization types, which determines how the data will be serialized between the business object and the JMS message.

    Message type is used by the server to create and send the outgoing message. It is used with some data format transformers. If the server does not use the message type specified then it is disabled. Valid types are byte, map, object, stream or text.

    Under JMS Headers, the properties you can specify are as follows. The JMS Type property conforms to the JMSType specified in the JMS specification. This property contains a message type identifier supplied by a client when a message is sent. The JMS Correlation ID property conforms to the JMSCorrelationID in the JMS specification. A typical use is to link a response message with its request message. In IBM Integration Designer, the ID is used by the message selector to select only messages with that ID. It can be any string value. JMS message properties can effectively be used to add optional header fields to a message. Custom Headers allows you to specify a name, type and value for a property.

  10. Selecting the Faults configuration tab lets you configure the faults specified on the operations in the interface. The configuration of faults is optional. The configuration can apply to all operations or a specific operation.

    If fault configuration is new to you, see Handling faults in bindings for an overview.

    Click Select beside Fault selector to configure a fault. Your selections are as follows:

    Specifying a fault selector requires that you also specify the data format for the fault. Click Select beside Business fault data format . Your selections are as follows:

    Expanding Advanced, lets you also specify the data format for a runtime exception.

  11. Selecting Security attributes shows the authentication properties under Authentication Properties section. The J2C Authentication Data Entry property is available to specify a name. If Advanced is selected, authentication properties are shown such as the level of the authentication; for example, at the container level.

    The Response Connection tab can be used to set the same properties on the response connection in the case of a request-response operation.

  12. The Message Configuration tab shows the correlation scheme for the response message. Request Message ID to Correlation ID adds a request ID to the request message. It is expected the reply copies the request ID to the correlation ID field of the response message so the caller can correlate the reply message with the request message. Request Correlation ID to Correlation ID adds the correlation ID to the request message. It is expected the reply copies the request correlation ID to the correlation ID field of the response message so the caller can correlate the reply message with the request message. Use a temporary dynamic destination for receiving responses uses a temporary destination for each request. This selection does not use a correlation ID as the import listens for responses on that destination.

    Failed message recovery mode lets you allow the binding to manage the recovery of failed messages (the default) or rely on the transport-specific method of recovery. Allow binding to manage recovery for failed messages creates a recovery queue on deployment to handle failed messages. Binding errors are handled as failed events that can be retrieved later. Rely on transport-specific recovery for failed events does not set up a recovery mechanism.

  13. The Propagation tab lets you select two types of context propagation. Context propagation takes information associated with a runtime or an application and passes it along with requests that are the result of interactions with that runtime or application. The default is to use runtime context propagation. See Propagation.

  14. Selecting the Summary tab specifies the send and receive (in the case of a request-response operation) JNDI names and managed connection factory name. They are names generated by the SCA JMS handler or defined by yourself when the application is deployed. These JNDI names may be necessary when authoring the targeted JMS application.


You have created a JMS binding for an import. Compare this approach with creating a JMS binding for an export, which is similar.



Related tasks:

Generating a JMS export binding


Generating a JMS export binding

Generate a JMS export binding with either a one-way operation or request-response operation is shown. Once generated, the binding properties are discussed.

Prerequisites: You should have a module.

If you intend to use the standard JMS message class with a body type containing the message then use the business objects provided for these body types (see Work with the simple JMS data bindings).

In this set of steps, you will learn how to create a JMS binding for an export. A JMS binding is used when you want to have your service accessed in an asynchronous manner from the WebSphere Default Messaging client.

  1. Open the assembly editor. Under Inbound Exports, select JMS and drag it to the assembly editor. Select an interface or create one.

    Alternately, under Components, select Export and drag it on to the canvas. An export with no implementation and no interface is created. Right-click the component, select Add Interface from the menu and add an interface that describes your interaction with a JMS application. Create an export with a JMS binding by right-clicking the component and from the menu selecting Generate Binding > Messaging Binding > JMS Binding.

  2. The Configure JMS Export Service window box opens. There is a slight difference between an interface with a one-way operation and an interface with a request-response operation. An interface with a request-response operation has an additional field for a send destination.

    Select the messaging domain: Point-to-Point or Publish-Subscribe.

    Select to Configure new messaging provider resources (the default) or Use pre-configured messaging provider resources. If you choose pre-configured, then add the JNDI names for the activation specification and the receive destination for a one-way operation, and receive and send destinations for a request-response operation.

    You should periodically check your binding configuration information at run time in the administrative console. In particular check the state of the endpoint. Under some conditions the endpoint may go into a paused state and restart it (see View or changing the state of an endpoint).

    If you specify JNDI names and then switch to specifying your own configuration properties both sets of values remain in memory until you close the editor. You are saved from reentering the values while you decide.

    In the Default data format field, select how the data will be serialized between the business object and the JMS message with a binding. To change the default, click Select beside the field to launch the Data Transformation Configuration window. Your selections are as follows:

    In the Function selector section, select the function selector configuration you want to use. A function selector selects an operation to invoke on your component at run time. Clicking Select beside the Function selector field, launches the Function Selector Configuration window and provides the following selections:

    In the next section, to use the default module to module fault handling, which is a SOAP transport, select it.

    A common way for specifying a userid and password is through using the Java EE Connector (J2C) authentication data entries. The entries are defined on the server. In the Security configuration section, select Specify a Java Authentication and Authorization Services (JAAS) alias security credential when server security is enabled, if it is used by your organization. Enter the Java EE Connector (J2C) authentication data entry.

    Click OK. The basic JMS binding is created and shown in the properties view when the Binding tab is selected.

  3. Selecting the Binding tab shows the adapter type, default data format selector, fault selector, runtime exception selector, and function selector that you previously specified.

    You can change the selections and, in the case of the data format, use a data handler if you are using a custom data format.

  4. Selecting the End-point configuration tab and the Connection tab, opens the connection properties. You may specify a JNDI lookup name. If a JNDI lookup name is specified then you are using an ActivationSpec configured on the server, so the ActivationSpec class and its properties will not be shown here. In addition, all sections except method bindings properties and authentication properties on the Security attributes tab will not be shown. In our case, a JNDI lookup name was not specified so the ActivationSpec will be created on the server using the properties specified here.

    The ActivationSpec Properties section specifies the properties for the ActivationSpec class, which represents the configuration required to establish the connection between the service and the messaging provider. Specifically, these properties specify the bus name, durability, destination type and mode, and advanced properties for concurrency and sharing of durable subscriptions. Advanced specifies the listener type.

  5. Beneath JMS Destinations in the Receive Destination Properties section, the type of destination and its properties are listed and can be changed. If you specify a JNDI name, this information is not available as it is configured on the server.

    If you specify nothing in the Queue Name or Topic Space field, a default value will be created. If you specify a queue name or a topic space, this value will remain even if you then clear the field. The only way to change the value is to specify a different value. A name is required because you initially generated a one-way or request-response operation, which requires a name for the destination.

    Selecting the Send Destination Properties section, specifies the type of destination and its properties for a send destination in a response-request operation. If you specify a JNDI name, this information is not available as it is configured on the server; that is, the destination specified on the server under this JNDI name will be used.

    If you specify nothing in the queue name or topic space field, a default value will be created. If you specify a queue name or a topic space, this value will remain even if you then clear the field. The only way to change the value is to specify a different value. A name is required because you initially generated a request-response operation, which requires a name for the destination.

    In the Callback Destination Properties section, the callback destination type may be specified or a JNDI name where the same information is specified.

  6. Selecting the Response Connection tab lists the managed connection factory properties and the administration connection properties of the response connection. The Managed Connection Factory Properties section specifies the managed connection factory class and its properties such as the service bus name and quality of service with respect to persistence, in the case of the WebSphere default messaging provider resource adapter. Other JMS resource adapters would have different properties. The necessary fields are completed for you. Advanced indicates if this is a shared connection property.

    Expanding Admin Connection Properties provides connection pool properties and configuration properties if you would like custom names and values. If you had specified an JNDI name earlier, it is empty since the server is determining connection pooling values and only an information name is present.

  7. Selecting Method bindings lists the methods beneath the Generic tab. By default, all methods are bound. However, some of these methods may not be needed for JMS usage. If so, clear the Bind method check box. The method binding has a native method attribute, which contains an identifier representing a JMS message. By default, the value of native method is set to the interface operation name when the JMS export is created. The JMS export utilizes a function selector to inspect an incoming message and return the name of the native method from a value in the message header.

    Data Serialization lets you specify serialization types for each input and output data binding in each method beneath the tab.

    Message type is used by the server to create and send the outgoing message. It is used with some data format transformers. If the server does not use the message type specified then it is disabled. Valid types are byte, map, object, stream or text.

  8. Selecting the Faults configuration tab lets you configure the business fault data format for the faults in the interface. The configuration of faults is optional. The configuration can apply to all operations, a specific operation or a specific fault.

    If fault configuration is new to you, see Handling faults in bindings for an overview.

    Click Select beside Business fault data format . Your selections are as follows:

  9. Selecting the Security attributes tab and the Connection tab and expanding the Authentication Properties section opens the authentication properties for a connection. The J2C Authentication Data Entry property is available to specify a name. If Advanced is selected, authentication properties are opened such as the level of the authentication; for example, at the container level.

    Selecting Response Connection and expanding the Authentication Properties section opens the authentication properties for the response connection. The J2C Authentication Data Entry property is available to specify a name. If Advanced is selected, authentication properties are opened such as the level of the authentication; for example, at the container level.

  10. Selecting the Message Configuration tab shows the correlation scheme for the response message.Request Message ID to Correlation ID adds a request ID to the request message. It is expected the reply copies the request ID to the correlation ID field of the response message so the caller can correlate the reply message with the request message. Request Correlation ID to Correlation ID adds the correlation ID to the request message. It is expected the reply copies the request correlation ID to the correlation ID field of the response message so the caller can correlate the reply message with the request message.

    The Asynchronous reliability property can have these values: assured (default) or bestEffort. Select assured if you want a message to persist through a transaction. In other words, if you want guaranteed delivery of the message. Select bestEffort if you want a high throughput of messages and your application can accept and handle the loss of a message, as persistence is not guaranteed.

    Event sequence required specifies if the sequence of messages is ordered and requires responses in the same order.

    Failed message recovery mode lets you allow the binding to manage the recovery of failed messages (the default) or rely on the transport-specific method of recovery. Allow binding to manage recovery for failed messages creates a recovery queue on deployment to handle failed messages. Binding errors are handled as failed events that can be retrieved later. Rely on transport-specific recovery for failed events does not set up a recovery mechanism.

  11. The Propagation tab lets you select two types of context propagation. Context propagation takes information associated with a runtime or an application and passes it along with requests that are the result of interactions with that run time or application. The default is to use runtime context propagation. See Propagation.

  12. Selecting the Summary tab specifies the receive and send (in the case of a request-response operation) JNDI names for destinations, the activation specification, and the response managed connection factory. The function selector class name is also specified. The JNDI names are generated by the SCA JMS handler or defined by yourself when the application is deployed. These JNDI names may be necessary when authoring the targeted JMS application.


You have created a JMS binding for your export. Compare this approach with creating a JMS import binding.



Related tasks:

Generating a JMS import binding


JMS, MQ JMS and generic JMS bindings

The bindings for JMS, MQ JMS and generic JMS are examined.



Overview of JMS, MQ JMS and generic JMS bindings

Bindings and their relationship to imports, exports, messages and data objects are discussed in this section.

The following sections discuss aspects of data bindings:


Data bindings

Data bindings handle the transformation of data passed as a Service Data Object (SDO) in a Service Component Architecture-based (SCA) application and the native format for an EIS J2C or messaging JMS system. The data binding function handles the request and response arguments for both inbound and outbound communication. Data bindings are described in chapter 9 of the Enterprise Metadata Discovery specification. This joint specification from IBM and BEA introduces a new metadata discovery and import model for resource adapters and the enterprise application integration (EAI) tools framework. The model allows resource adapters to plug into an integration framework and improves the usability of adapters within the framework. This specification also includes API information on methods discussed in this section.

The DataBinding interface expresses the contract for the service client, allowing a DataObject to be set or retrieved. All data bindings must implement the commonj.connector.runtime.DataBinding interface as shown in the following example:

public interface DataBinding extends Serializable {

 public DataObject getDataObject() throws DataBindingException;
 public void setDataObject(DataObject dataObject) throws DataBindingException;}

From a service binding, there are three specializations provided: one for Java EE Connector Architecture (J2C), one for JMS and one for MQ.

When an EIS or messaging import is invoked, a data binding is used to transform the content of a Service Data Object (SDO) into the native format of the EIS or messaging system by the SCA runtime, and when the reply (if any) is received from the EIS or messaging import, the data binding is used to transform the native data format into an SDO. When an EIS or messaging export is invoked, a data binding is used to transform the native data format into an SDO, and when the reply (if any) is sent back to the caller a data binding is used to transform the content of the SDO into the native format of the EIS or messaging system. SDOs in the SCA environment are business objects.

A data binding can be specified in the root portion of an import or export binding. This simplifies the model when a common data binding is used for all input and output arguments of the binding. A specific data binding can also be specified on the method binding for input and output arguments. A data binding specified at the method level takes precedence over the data binding specified at the root level of the binding.

For EIS, a data binding generator can also be specified for the EIS import or export binding. The data binding generator must be specified in the root portion. The EIS SCA implementation will then use it to generate a data binding for each input and output argument.

A data binding generator can also be used with JMS.

On the left side of the following diagram, a JMS messaging provider makes a request (that is, invokes an operation in an SCA application) and receives a response (that is, some data) from that application. When the messaging provider initiates the call to an SCA function, it uses an export to access the SCA application.

On the right side of the diagram, an SCA application makes a request to the JMS provider, which in turn would invoke a method in an application. The SCA application receives a response from the application. When the SCA application initiates the call to a function outside the SCA application, it uses an import.

  1. JMS export binding elements:

    • A Web Services Description Language (WSDL) interface on the export lists the operations available in the SCA application and specifies the types of data that can be passed to the SCA application.
    • A data binding specifies the transformation of the data from a native format, for example, a stream of bytes, to an SCA format such as XML.
    • A function selector data binding specifies the operation to invoke on the SCA application.

  2. JMS import binding elements:

    • A WSDL interface on the import lists the operations that will be invoked on the remote application; that is, the application outside the SCA application containing the import.
    • A data binding specifies the transformation of the data from an SCA format, for example, XML, to a native format such as a stream of bytes.


JMS data bindings

In the case of a JMS export binding, the format and structure of each incoming message must be known by the data binding implementation, which turns it into a data object (DataObject object). In the case of a JMS import binding, the reverse occurs; namely, the outgoing data object is turned into the JMS message that is sent to the external service. The data binding defined for the JMS Service must implement the com.ibm.websphere.sca.jms.data.JMSDataBinding interface shown in the following example.

public interface JMSDataBinding extends DataBinding {

 public void read(javax.jms.Message message) throws javax.jms.JMSException;

 public void write(javax.jms.Message message) throws javax.jms.JMSException;

 public int getMessageType();

 public boolean isBusinessException();

 public void setBusinessException(boolean isBusinessException);

 static public int OBJECT_MESSAGE = 0;

 static public int TEXT_MESSAGE = 1;

 static public int BYTES_MESSAGE = 2;

 static public int STREAM_MESSAGE = 3;

 static public int MAP_MESSAGE = 4;

 static public int JMS_MESSAGE = 5;
}

This data binding interface for the JMS service allows for the conversion of data between the data object and the message. For two of the message types, the native format is well defined, so two default implementations are supplied for the JMSObjectMessage and JMSTextMessage types:

If the native format of the JMS message does not conform to one of the two well defined formats, then an implementation of the JMSDataBinding must be provided to handle the data transformation to and from a DataObject. To implement a JMS data binding, an implementation must provide implementations for the following methods:

An example of using the JMSDataBinding can be seen in Create a user-defined JMS data binding.

Fault handling using these methods could be implemented in a similar manner to the following code:

public class Foo implements JMSDataBinding {

    private boolean fieldIsBusinessException = false;

    public boolean isBusinessException() {
       
        return fieldIsBusinessException;
    }

    public void setBusinessException(boolean isBusinessException) {
    
     this.fieldIsBusinessException = isBusinessException;
    }

 public void read(Message message) throws JMSException {
  ...
 if(message.propertyExists("IsBusinessException")){
   this.fieldIsBusinessException = message.getBooleanProperty("IsBusinessException");
  } else{ // Unknown other side, default to false    this.fieldIsBusinessException = false;
  }

 }


 public void write(Message message) throws JMSException {
            ...
  message.setBooleanProperty("IsBusinessException", this.fieldIsBusinessException);
 }}

A data object can be created by using the following line of code, where the namespace is the target namespace of the data object and the name is the name of the data object to be created:

com.ibm.websphere.sca.ServiceManager serviceManager = new
  com.ibm.websphere.sca.ServiceManager();
com.ibm.websphere.bo.BOFactory factory =
(com.ibm.websphere.bo.BOFactory)serviceManager.locateService("com/ibm/websphere/bo/BOFactory");
 DataObject dataObject = factory.create("http://CICSTest/data", "Taderc99");


MQ JMS and MQ data bindings

The MQ JMS data bindings are similar to the JMS data bindings. The default data bindings are serialized business objects using JMSObjectMessage and business object XML using JMSTextMessage, which use the com.ibm.websphere.sca.jms.data.impl.JMSDataBindingImplJava and com.ibm.websphere.sca.jms.data.impl.JMSDataBindingImplXML classes. A user supplied data binding allows you to specify your own data binding, though it must conform to the JMS data binding interface. The message content of an MQ JMS data binding is accessed through the JMS API.

WebSphere MQ has its own unique set of data bindings, which are discussed in Overview of MQ data format transformations.


Operation types and input and output for JMS data bindings

The expected argument that will be passed to the JMSDataBinding and JMSObjectBinding depend on the interface operation and the input, output and fault types. In the export case, this is the expected payload of the JMS message that should be coming on the incoming JMS destination.

For faults, the outDataBindingType specified on the method binding is used. If none is specified, the binding level dataBindingType is used for all serialization and deserialization.

For non-Document-Literal wrapped style interfaces, there is no unwrapping and the expected arguments to the data bindings are the input and output of the operations.

For Document-Literal wrapped style interfaces the argument is unwrapped and the underlying data is passed.

The following sections show the various mappings.

WSDL interface operation for request-response operation using document literal wrapped style with a single argument

<xsd:element name="loginAccount">
 <xsd:complexType>
  <xsd:sequence>
   <xsd:element name="credentials" nillable="true"
    type="bons1:CredentialsBO" />
  </xsd:sequence>
 </xsd:complexType>
</xsd:element>
<xsd:element name="loginAccountResponse">
 <xsd:complexType>
  <xsd:sequence>
   <xsd:element name="response" nillable="true"
    type="xsd:string" />
  </xsd:sequence>
 </xsd:complexType>
</xsd:element>
<xsd:element name="loginAccount_fault1" type="xsd:string" />
</wsdl:types>
<wsdl:message name="loginAccountRequestMsg">
 <wsdl:part element="tns:loginAccount" name="loginAccountParameters" />
</wsdl:message>
<wsdl:message name="loginAccountResponseMsg">
 <wsdl:part element="tns:loginAccountResponse"
  name="loginAccountResult" />
</wsdl:message>
<wsdl:message name="loginAccount_fault1Msg">
 <wsdl:part element="tns:loginAccount_fault1" name="fault1" />
</wsdl:message>
<wsdl:operation name="loginAccount">
 <wsdl:input message="tns:loginAccountRequestMsg"
  name="loginAccountRequest" />
 <wsdl:output message="tns:loginAccountResponseMsg"
  name="loginAccountResponse" />
 <wsdl:fault message="tns:loginAccount_fault1Msg"
  name="credentialsError" />
</wsdl:operation>

Operation and input and output type

Request-response

  • Input: Doc-Lit Wrapped Style with Single argument Data object
  • Output: Doc-Lit Wrapped Style with Single argument simple type
  • Fault: Simple type

Object set on JMS data binding and support

  • Input: DataObject Requires: JMSDataBinding
  • Output: Simple Type: Requires: JMSObjectBinding
  • On Input: DataObject representing contents of CredentialsBO
  • On Output: String value for response.
  • Fault: String representing fault data. IsBusinessException is set to true.

WSDL interface operation for one-way operation using document literal wrapped style with a single argument

<xsd:element name="selectAccount">
 <xsd:complexType>
  <xsd:sequence>
   <xsd:element name="accountName" nillable="true"
    type="xsd:string" />
  </xsd:sequence>
 </xsd:complexType>
</xsd:element>
</wsdl:message>
<wsdl:message name="selectAccountRequestMsg">
 <wsdl:part element="tns:selectAccount"
  name="selectAccountParameters" />
</wsdl:message>
<wsdl:operation name="selectAccount">
 <wsdl:input message="tns:selectAccountRequestMsg"
  name="selectAccountRequest" />
</wsdl:operation>

Operation and input and output type

One-way

  • Input: Doc Lit wrapped style with single argument String (simple type)

Object set on JMS data binding and support

  • Input: Simple Type Requires:JMSObjectBinding
  • On Input: String Object.

WSDL interface operation for request-response operation using document literal wrapped style with multiple arguments

<xsd:element name="updateAccount">
 <xsd:complexType>
  <xsd:sequence>
   <xsd:element name="performCredit" nillable="true"
    type="xsd:boolean" />
   <xsd:element name="amount" nillable="true" type="xsd:float" />
  </xsd:sequence>
 </xsd:complexType>
</xsd:element>
<xsd:element name="updateAccountResponse">
 <xsd:complexType>
  <xsd:sequence>
   <xsd:element name="balance" nillable="true"
    type="xsd:float" />
  </xsd:sequence>
 </xsd:complexType>
</xsd:element>
</wsdl:message>
<wsdl:message name="updateAccountRequestMsg">
 <wsdl:part element="tns:updateAccount"
  name="updateAccountParameters" />
</wsdl:message>
<wsdl:message name="updateAccountResponseMsg">
 <wsdl:part element="tns:updateAccountResponse"
  name="updateAccountResult" />
</wsdl:message>
<wsdl:message name="updateAccount_fault1Msg">
 <wsdl:part element="tns:updateAccount_fault1" name="fault1" />
</wsdl:message>
<wsdl:operation name="updateAccount">
 <wsdl:input message="tns:updateAccountRequestMsg"
  name="updateAccountRequest" />
 <wsdl:output message="tns:updateAccountResponseMsg"
  name="updateAccountResponse" />
 <wsdl:fault message="tns:updateAccount_fault1Msg"
  name="insufficientFunds" />
</wsdl:operation>

Operation and input and output type

Request-response

  • Input: Doc Lit wrapped style with multiple arguments, which are simple types. DataObject with 2 simple types as properties
  • Output: Doc Lit wrapped style with single argument, which is simple type.
  • Fault: DataObject

Object set on JMS data binding and support

  • Input: DataObject with 2 arguments Requires: JMSDataBinding
  • Output: Simple Type Requires: JMSObjectBinding
  • Fault: DataObject representing the fault message. Requires: JMSDataBinding

WSDL interface operation for request-response operation using document literal wrapped style with multiple arguments of mixed types

<xsd:element name="updateAccount2">
 <xsd:complexType>
  <xsd:sequence>
   <xsd:element name="performCredit" nillable="true"
    type="xsd:boolean" />
   <xsd:element name="amount" nillable="true" type="xsd:float" />
   <xsd:element name="dummyInfo" nillable="true"
    type="bons1:DummyBO" />
  </xsd:sequence>
 </xsd:complexType>
</xsd:element>
<xsd:element name="updateAccount2Response">
 <xsd:complexType>
  <xsd:sequence>
   <xsd:element name="balance" nillable="true"
    type="xsd:float" />
  </xsd:sequence>
 </xsd:complexType>
</xsd:element>
</wsdl:message>
<wsdl:message name="updateAccount_fault1Msg">
 <wsdl:part element="tns:updateAccount_fault1" name="fault1" />
</wsdl:message>
<wsdl:message name="updateAccount2RequestMsg">
 <wsdl:part element="tns:updateAccount2"
  name="updateAccountParameters" />
</wsdl:message>
<wsdl:message name="updateAccount2ResponseMsg">
 <wsdl:part element="tns:updateAccount2Response"
  name="updateAccountResult" />
</wsdl:message>
<wsdl:operation name="updateAccount2">
 <wsdl:input message="tns:updateAccount2RequestMsg"
  name="updateAccount2Request" />
 <wsdl:output message="tns:updateAccount2ResponseMsg"
  name="updateAccount2Response" />
 <wsdl:fault message="tns:updateAccount_fault1Msg"
  name="insufficientFunds" />
</wsdl:operation>

Operation and input and output type

Request-response

  • Input: DocLit wrapped style with multiple arguments (Mixed Types), which are simple types and a DataObject DataObject with 2 simple types and a DataObject as properties
  • Output: Doct Lit wrapped style with single argument, which is simple type.
  • Fault: DataObject

Object set on JMS data binding and support

  • Input: DataObject with 3 arguments Requires: JMSDataBinding
  • Output: SimpleType Requires: JMSObjectBinding
  • On Fault: DataObject representing the fault message. Requires: JMSDataBinding

WSDL interface operation for request-response operation using document literal wrapped style with a no arguments

<xsd:element name="getCustomerInfo">
 <xsd:complexType>
  <xsd:sequence />
 </xsd:complexType>
</xsd:element>
<xsd:element name="getCustomerInfoResponse">
 <xsd:complexType>
  <xsd:sequence>
   <xsd:element name="result" nillable="true"
    type="bons1:CustomerInfoBO" />
  </xsd:sequence>
 </xsd:complexType>
</xsd:element>
</wsdl:message>
<wsdl:message name="getCustomerInfoRequestMsg">
 <wsdl:part element="tns:getCustomerInfo"
  name="getCustomerInfoParameters" />
</wsdl:message>
<wsdl:message name="getCustomerInfoResponseMsg">
 <wsdl:part element="tns:getCustomerInfoResponse"
  name="getCustomerInfoResult" />
</wsdl:message>
<wsdl:operation name="getCustomerInfo">
 <wsdl:input message="tns:getCustomerInfoRequestMsg"
  name="getCustomerInfoRequest" />
 <wsdl:output message="tns:getCustomerInfoResponseMsg"
  name="getCustomerInfoResponse" />
</wsdl:operation>

Operation and input and output type

Request-response

  • Input: Doc Lit wrapped style, with no arguments (null). DataObject representing wrapper, used and no properties.
  • Output: Doc Lit wrapped style, with Data Object

Object set on JMS data binding and support

  • Input: DataObject set to null. Requires: JMSDataBinding
  • Output:DataObject represenitng the value contained in the wrapper. Requires: JMSDataBinding

WSDL interface operation for request-response operation using document literal wrapped style with a data object

<xsd:element name="updateCustomerInfo">
 <xsd:complexType>
  <xsd:sequence>
   <xsd:element name="customerInfo" nillable="true"
    type="bons1:CustomerInfoBO" />
  </xsd:sequence>
 </xsd:complexType>
</xsd:element>
<xsd:element name="updateCustomerInfoResponse">
 <xsd:complexType>
  <xsd:sequence>
   <xsd:element name="result" nillable="true"
    type="bons1:CustomerInfoBO" />
  </xsd:sequence>
 </xsd:complexType>
</xsd:element>
</wsdl:message>
<wsdl:message name="updateCustomerInfoRequestMsg">
 <wsdl:part element="tns:updateCustomerInfo"
  name="updateCustomerInfoParameters" />
</wsdl:message>
<wsdl:message name="updateCustomerInfoResponseMsg">
 <wsdl:part element="tns:updateCustomerInfoResponse"
  name="updateCustomerInfoResult" />
</wsdl:message>
<wsdl:operation name="updateCustomerInfo">
 <wsdl:input message="tns:updateCustomerInfoRequestMsg"
  name="updateCustomerInfoRequest" />
 <wsdl:output message="tns:updateCustomerInfoResponseMsg"
  name="updateCustomerInfoResponse" />
</wsdl:operation>

Operation and input and output type

Request-response

  • Input: Doc Lit wrapped style, with DataObject
  • Output: Doc Lit wrapped style, with Data Object

Object set on JMS data binding and support

  • Input: DataObject representing the value contained in the wrapper. Requires: JMSDataBinding
  • Output: DataObject representing the value contained in the wrapper. Requires: JMSDataBinding

WSDL interface operation for request-response operation using document literal wrapped style with two data object arguments

<xsd:element name="updateCustomerInfo2">
 <xsd:complexType>
  <xsd:sequence>
   <xsd:element name="customerInfo" nillable="true"
    type="bons1:CustomerInfoBO" />
   <xsd:element name="dummyInfo" nillable="true"
    type="bons1:DummyBO" />
  </xsd:sequence>
 </xsd:complexType>
</xsd:element>
<xsd:element name="updateCustomerInfo2Response">
 <xsd:complexType>
  <xsd:sequence>
   <xsd:element name="result" nillable="true"
    type="bons1:CustomerInfoBO" />
  </xsd:sequence>
 </xsd:complexType>
</xsd:element>
</wsdl:message>
<wsdl:message name="updateCustomerInfo2RequestMsg">
 <wsdl:part element="tns:updateCustomerInfo2"
  name="updateCustomerInfoParameters" />
</wsdl:message>
<wsdl:message name="updateCustomerInfo2ResponseMsg">
 <wsdl:part element="tns:updateCustomerInfo2Response"
  name="updateCustomerInfoResult" />
 <wsdl:operation name="updateCustomerInfo2">
  <wsdl:input message="tns:updateCustomerInfo2RequestMsg"
   name="updateCustomerInfo2Request" />
  <wsdl:output message="tns:updateCustomerInfo2ResponseMsg"
   name="updateCustomerInfo2Response" />
 </wsdl:operation>
</wsdl:message>

Operation and input and output type

Request-response

  • Input: Doc Lit wrapped style, with 2 arguments of type DataObject
  • Output: Doc Lit wrapped style, with Data Object

Object set on JMS data binding and support

Request-response

  • Input: DataObject representing wrapper with the argument DataObject as properties. Requires: JMSDataBinding
  • Output: DataObject representing the value contained in the wrapper. Requires: JMSDataBinding

WSDL interface operation for request-response operation with a data object representing a JmsQuote data element

<wsdl:types>
 <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <xsd:import namespace="http://jms.quote.data"
   schemaLocation="JmsQuote.xsd">
  </xsd:import>
 </xsd:schema>
</wsdl:types>

<wsdl:message name="JmsQuoteRequest">
 <wsdl:part name="request" element="data:JmsQuote"></wsdl:part>
</wsdl:message>

<wsdl:message name="JmsQuoteReply">
 <wsdl:part name="request" element="data:JmsQuote"></wsdl:part>
</wsdl:message>

<wsdl:portType name="JmsQuotePT">
 <wsdl:operation name="getJmsQuote">
  <wsdl:input message="tns:JmsQuoteRequest"></wsdl:input>
  <wsdl:output message="tns:JmsQuoteReply"></wsdl:output>
 </wsdl:operation>
</wsdl:portType>

Operation and input and output type

Request-response

  • Input: DataObject representing JmsQuote
  • Output: DataObject representing JmsQuote

Object set on JMS data binding and support

  • Input: DataObject Requires: JMSDataBinding
  • Output: DataObject Requires: JMSDataBinding


Data binding generator

A data binding generator is an implementation class, which at application assembly time will generate a type specific data binding implementation for an input or output parameter of a particular operation. The data binding generator generates a standard implementation class unlike the unique custom data binding. It automates the process of implementing a data binding.

The generator is invoked during application assembly, when the artifacts needed to deploy SCA module are generated. This approach ensures the data binding implementation is always matching the latest version of the possibly edited type (schema). The commonj.connector.metadata.description.DataBindingGenerator interface is presented as follows:

public interface DataBindingGenerator {

    public DataBindingDescription[] generateDataBinding(
    QName complexType, URL schema)
     throws MetadataException;}

For the generateDataBinding() method, it passes as arguments the QName of the input or output complexType and the URL of its schema. The complexType QName refers to a global complexType. The DataBindingGenerator implementation is then responsible for loading the schema, including resolving any schema imported or included. It then finds the complex type definition specified by the QName, and by looking at it or annotations in the schema generates one or more data bindings to handle the complex type definition.

For the generator to be found at application assembly time, it must be registered by using the extension point "connector.metadata.databinding_generator" or be supplied by and be in the classpath of the resource adapter. The class name is specified in the root portion of an import or export binding. The lookup depends if the generator was registered by extension point, or is part of the resource adapter. If it is registered by extension point, the regular Eclipse extension point mechanisms are used to load the class. If the generator is part of the resource adapter, then the lookup for the generator class is done using the class name and looking in the classes supplied by the resource adapter. So the lookup is for a specific class on the classpath of the resource adapter.

The following is an example of this extension:

<extension point="connector.metadata.databinding_generator">
 <databinding_generator
  class="com.xyz.DataBindingGenerator"
  name="My Generator"
  id="com.xyz.DataBindingGenerator"/>
</extension>



Related concepts:

Prepackaged JMS data format transformations

JMS function selectors


Related reference:

Data handlers

Work with the simple JMS data bindings

Business object XML using JMS text message serialization

Prepackaged JMS and MQ fault selectors


Prepackaged JMS data format transformations

Several JMS data format transformations are packaged with BPM.

A description of each prepackaged data transformation follows in this table.

If you intend to use the standard JMS message class with a body type containing the message then use the business objects provided for these body types. To create these business objects, a predefined resource is available. To add this predefined resource, expand your module and then double-click Dependencies. The Dependencies editor opens. Expand Predefined Resources and select Native Body Schema for Native Body DataHandler. Save your work. You should also read Work with the simple JMS data bindings).

Note the data format transformations you see listed when you make a selection are filtered by the ones available in that context.

Prepackaged JMS data format transformations

Data format transformation Description Simple type supported?
Atom The data format transformation serializes a business object to an Atom feed when sending a message and parses Atom feed to a business object when receiving a message. This data format transformation must be configured. Select the Atom schema predefined resource in the dependency editor if using this transformation. No
Delimited This data format transformation serializes the business object to and from a delimited format in the message sent and received from the JMS client. This data format transformation must be configured. See Delimited format. No
FixedWidth This data format transformation serializes the business object to and from a fixed width format in the message sent and received from the JMS client. This data format transformation must be configured. See Fixed width format. No
Handled by WTX The data format transformation is delegated to the WebSphere Transformation Extender (WTX). The WTX map name is derived by the data handler. See WTX data handler. No
Handled by WTX Invoker The data format transformation is delegated to the WebSphere Transformation Extender (WTX). The WTX map name is supplied by the user. No
JAXB-based Java™ code This data format transformation serializes Java code to a business object using the Java Architecture for XML Binding (JAXB) specification receiving a message and deserializes a business object to Java code using the JAXB specification when sending a message. No
Service Gateway Data Handler The data format transformation uses the messageType property to determine which JMS body type will be used. The body type - BytesBody, ObjectBody, MapBody, StreamBody and TextBody - identifies the data format transformation to use. No
JSON This data format transformation sends and receives a business object based on JavaScript Object Notation (JSON) from the JMS client. This data format transformation must be configured. See JavaScript Object Notation (JSON) format. No
Serialized Java Object This data format transformation sends and receives the business object, whose underlying implementation is a service data object (SDO) in a JMS object message, to and from the JMS client. This serialization type is preferred when dealing with other SOA components using JMS. Yes
Simple JMS Message Data Binding This data format transformation does not have a message body. It can be used to notify the JMS client of an event or to send some simple data in the message headers or properties. No
Wrapped Bytes This data format transformation sends and receives the BytesBody business object in a BytesMessage message body to the client. The message body type is a byte array. Though still supported, a preferred method would be to use the data format transformations added when you select the Native Body schema for Native Body DataHandler in the Predefined Resources as stated in the introduction to this table. No
Wrapped MapEntry This data format transformation sends and receives the MapBody business object in a MapMessage message body to the client. The message body type is a set of name/value pairs that can be addressed by name. The data type of the value is a Java primitive. Though still supported, a preferred method would be to use the data format transformations added when you select the Native Body schema for Native Body DataHandler in the Predefined Resources as stated in the introduction to this table. No
Wrapped Object This data format transformation sends and receives the ObjectBody business object in an ObjectMessage message body to the client. The message body type is a serialized Java Object. Though still supported, a preferred method would be to use the data format transformations added when you select the Native Body schema for Native Body DataHandler in the Predefined Resources as stated in the introduction to this table. No
Wrapped StreamMessage This data format transformation sends and receives the StreamBody business object in a StreamMessage message body to the client. The message body type is a stream of Java primitives. Though still supported, a preferred method would be to use the data format transformations added when you select the Native Body schema for Native Body DataHandler in the Predefined Resources as stated in the introduction to this table. No
Wrapped Text This data format transformation sends and receives the TextBody business object to the TextMessage body of the client. Though still supported, a preferred method would be to use the data format transformations added when you select the Native Body schema for Native Body DataHandler in the Predefined Resources as stated in the introduction to this table. No
SOAP The SOAP data format transformation parses the body of a SOAP message into a business object when receiving a message. It serializes a business object and places it in the body of a SOAP message when sending a message. Yes
XML This data format transformation takes an XML data format as input and transforms it to a business object. It takes a business object output and transforms it to an XML data format. All character encoding sets (CCSIDs) are supported. Yes
UTF8XMLDataHandler This data format transformation parses UTF-8 encoded XML data into a business object when receiving a message. It serializes a business object into UTF-8 encoded XML data when sending a message. Yes

You can also create a new data format transformation configuration .



Related concepts:

JMS function selectors


Related reference:

Overview of JMS, MQ JMS and generic JMS bindings

Data handlers

Work with the simple JMS data bindings

Business object XML using JMS text message serialization

Prepackaged JMS and MQ fault selectors


Data handlers

Data handlers are used when you need a specific data format transformation that is not in the standard set of prepackaged data format transformations.

In effect, data handlers allow you to customize a data format transformation for your particular needs. Data handlers are reusable transformation logic independent of a specific transport protocol, which means you can create a data handler and use it with JMS, MQ, HTTP, EIS and other bindings. Data handlers can be invoked from data bindings and Java™ components.

To learn how to create a data handler, see Data handlers.

To learn how to add a data handler to a data format transformation, see Create a data format transformation resource configuration.





Related concepts:

Prepackaged JMS data format transformations

JMS function selectors

Prepackaged MQ data format transformations

Prepackaged MQ function selectors

Overview of HTTP data bindings

Prepackaged HTTP data format transformations

Overview of HTTP function selectors

Prepackaged HTTP function selectors


Related reference:

Overview of JMS, MQ JMS and generic JMS bindings

Work with the simple JMS data bindings

Business object XML using JMS text message serialization

Prepackaged JMS and MQ fault selectors

Overview of MQ data format transformations

Overview of the MQ function selectors

Prepackaged HTTP fault selectors


Work with the simple JMS data bindings

Use JMS data bindings when you implement a standard JMS message body type.

A standard schema is defined for messaging types as a data handler that uses a data binding. The data handler, Native Body Schema for Native Body DataHandler, is the standard JMS data handler for all message types. To add this predefined resource, expand your project and then double-click Dependencies. The Dependencies editor opens. Expand Predefined Resources to select the data handler. Save your work.

The JMS standard defines a message class (javax.jms.Message). This message class is the root interface for all JMS messages. It defines the message header, the acknowledge method used for all messages and properties but no body (payload). Five message subclasses are defined for the data handler, each of which has a different body type:

WebSphere Integration Designer supplies JMS data bindings for predefined JMS message body types:

The data bindings display in the Data area of your project after you have selected the Native Body Schema for Native Body DataHandler. When use the data bindings for standard JMS message body types, add the service gateway interface and schema files if you are building a static service gateway. In your module, open the dependencies editor. Under Predefined Resources, select Service gateway interface. Save your work and close the dependencies editor.

Two specialized JMS data bindings also exist, one for Text and one for Object messages. The Text binding requires the message body to be an XML description of a message. The Object binding requires the message body to be a serialized data object. These bindings are general purpose and support any message body.

For Text and Bytes messages, the bindings treat the message payload as unstructured data and transfer it as a whole into the corresponding business object. In certain cases, the data and map elements (of the message payload) need to be parsed into a structure within a business object. This happens when the data is structured. In those cases, you must provide your own data bindings and business object definitions.

You might also be mapping elements of the object, rather than the whole object, into a business object. In that case, you must provide your own data bindings and business object definitions for the Object Message.

A delimited data binding is available for cases where the message body is in a format delimited by a comma (,). A fixed width data binding is available for cases where the message body is in a fixed width format.

A JMS adapter language data binding generator binding treats the message body as a language supported by the JMS adapter such as COBOL.

The nine standard JMS data bindings can be used when you have a simple message or you want to perform routing without looking at message content. You would choose the Text or Object data bindings if you have business objects you want to work with. Use the delimited or fixed width data bindings when the message body contains a message in those formats. Use the JMS adapter language data binding when the message body is in a language like COBOL.

When you create an interface with request or request-response operations for interacting with the destinations of messaging providers, the input and output data types must match your use case. For example, if you are performing message routing with a flow component, use the appropriate JMS type. If you are processing the data then use a type that matches the message body.

You can also use a WebSphere Transformation Extender (WTX) data binding. The transformation extender data binding is a universal validation and transformation engine that converts business objects to other data formats.



Related concepts:

Prepackaged JMS data format transformations

JMS function selectors


Related reference:

Overview of JMS, MQ JMS and generic JMS bindings

Data handlers

Business object XML using JMS text message serialization

Prepackaged JMS and MQ fault selectors


Business object XML using JMS text message serialization

Business object XML using the JMS TextMessage interface serializes the business object to and from XML and uses a JMS text message to communicate with the JMS client. The serialization for an anonymous schema type or a named schema type is described in this section.


Business object defined using an anonymous schema type

If the business object is defined by a schema using an anonymous type such as the following code:

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
 targetNamespace="http://ModuleTest">
 <xsd:element name="Employee">
  <xsd:complexType>
   <xsd:sequence>
    <xsd:element minOccurs="0" name="name"
     type="xsd:string" />
    <xsd:element minOccurs="0" name="empno"
     type="xsd:string" />
   </xsd:sequence>
  </xsd:complexType>
 </xsd:element>
</xsd:schema>

Then the contents of the JMS text message would be the following code:

<?xml version="1.0" encoding="UTF-8"?>
<module:Employee xmlns:module="http://ModuleTest">
 <name>Name1</name>
 <empno>007</empno>
</module:Employee>


Business object defined using a named schema type

If the business object is defined by a schema using a named type such as the following code:

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
 xmlns:tns="http://ModuleTest" targetNamespace="http://ModuleTest">
 <xsd:element name="Employee" type="tns:EmployeeType"></xsd:element>
 <xsd:complexType name="EmployeeType">
  <xsd:sequence>
   <xsd:element minOccurs="0" name="name" type="xsd:string" />
   <xsd:element minOccurs="0" name="empno" type="xsd:string" />
  </xsd:sequence>
 </xsd:complexType>
</xsd:schema>

Then the contents of the JMS text message would be the following code:

<?xml version="1.0" encoding="UTF-8"?>
<module:Employee xmlns:module="http://ModuleTest">
 <name>Name1</name>
 <empno>007</empno>
</module:Employee>



Related concepts:

Prepackaged JMS data format transformations

JMS function selectors


Related reference:

Overview of JMS, MQ JMS and generic JMS bindings

Data handlers

Work with the simple JMS data bindings

Prepackaged JMS and MQ fault selectors


JMS function selectors

The purpose of the JMS function selectors and the different types available are discussed



Related concepts:

Prepackaged JMS data format transformations


Related reference:

Overview of JMS, MQ JMS and generic JMS bindings

Data handlers

Work with the simple JMS data bindings

Business object XML using JMS text message serialization

Prepackaged JMS and MQ fault selectors


Overview of JMS function selectors

When a message arrives on a destination, the function selector is used to determine which operation corresponds to the message.

Some function selectors are supplied. In the default function selector section, we discuss the general behavior of a function selector and the implementation of the default function selector. In the standard JMS message function selector section, we discuss a particular function selector for the body types used by this standard.



Related concepts:

Prepackaged JMS function selectors


Default JMS function selector

The default JMS function selector is described.


Default function selector

There has to be some mechanism that can be used to determine which of the possible JMS or MQ JMS export components the message should be delivered to, and which SCA operation the message corresponds with. A JMS or MQ JMS message contains only data, and the message may contain an indication about the target operation, but there is not a standard way to retrieve this information. Therefore, we need to map a certain message to a certain operation of the targeted service interface. The JMS or MQ JMS export listens to a particular destination. When a message arrives to that destination, the function selector determines the target operation.

In the export binding, the method binding has a native method , which contains an identifier representing a JMS or MQ JMS message. Use of the native method allows for a level of indirection, which enables rename of an operation, without affecting the mapping.

By default, the value of native method is set to the interface operation name when the export is created. The export utilizes a function selector to inspect an incoming message in the message header or the message body. The export provides a default function selector that returns the value of JMS String Property TargetFunctionName from the header. So to identify the JMS or MQ JMS messages, the default behavior is for the import to set the JMS header property TargetFunctionName to the name of the interface operation name, and the default function selector used by the export will extract the TargetFunctionName property from the JMS header to correctly identify the incoming message. If the manner in which the native method name is to be found does not use the TargetFunctionName property, then a FunctionSelector implementation must be provided to correctly map the incoming JMS message to its intended SCA operation.

The commonj.connector.runtime.FunctionSelector interface presented below is used to extract the native function name or identifier (event ID) from the native data flowing inbound from the resource adapter using an EIS export.

public interface FunctionSelector {

 public String generateEISFunctionName(Object[] argObjects)
   throws SelectorException;
}

The implementation of this interface has to be provided by a resource adapter or third party who understands how to locate in the native data the appropriate identifier.

The implementation for the default JMS function selector basically looks like the following:

public class JMSFunctionSelectorImpl implements FunctionSelector {

 public String generateEISFunctionName(Object[] argObjects)
   throws SelectorException {

  try {
   Message message = (Message) argObjects[0];
   String functionName = message      .getStringProperty("TargetFunctionName");
   return functionName;
  } catch (Throwable e) {
   throw new SelectorException(e);
  }
 }}

Some other possible implementations for a FunctionSelector could use the JMSType header property or hard code the name of the method on the interface. Why would you hard code the name of the method on the interface? You would only hard code the name of the method if there were only one target SCA operation and that operation had a single input or output. Using the header property would typically be done for routing the message, performing some parsing and applying some logic to the parsed message. But suppose your application does not require any routing? A hard coded value in this case would make sense.

public class JMSFunctionSelectorImpl implements FunctionSelector {

    public String generateEISFunctionName(Object[] argObjects) throws SelectorException {
 
 return "handleMessage";}

Another possible implementation is to have the SCA application handle the routing. The mapped SCA operation would decide how to dispatch the message and then another part of the application would parse the message contents represented by its Service Data Object (SDO).

The following method demonstrates how a JMSType function selector could be used to create a name for the function:

public String generateEISFunctionName(Object[] arg)
   throws SelectorException {

  try {
   Message message = (Message) arg[0];
   String type = message.getJMSType();
   return type;
  } catch (JMSException e) {
   // Todo - Auto-generated catch block
   throw new SelectorException(e);
  }
 }



JMS function selector

The JMS function selector for the JMS standard of defining a message class with subclasses for the payload is discussed.


Standard JMS message function selector

A second function selector is available that follows the JMS standard of defining a message class with five subclasses of the message class for the body or payload which contains the message itself. Each subclass has a different body type. This function selector uses the JMSType property of the message to select the operation name.

The function selector is com.ibm.websphere.jms.data.bindings.JMSFunctionSelector.

To simplify working with this function selector, a function has been added to generate the appropriate business objects for the body types. In the dependencies editor of a module beneath the Predefined Resources heading, selecting Native Body schema for Native Body DataHandler and saving the dependencies generates the business objects for these body types. You can then use these business objects to represent the message from the JMS client.

These data bindings could be used for routing messages. For example, using a mediation module between an export and two imports, a message filter primitive examines the values in the message properties and routes high priority messages to one destination and lower priority messages to another destination. Another possible use could be to add an mapping transformation or database lookup mediation primitive between an export and import to modify the message.

The following table shows the relationship of the predefined resource, the body type, the business object created for it, and the data type for standard JMS messages.

Relationship of predefined resource, body type, business object and data type for standard JMS messages

Predefined resource Body type Business object Data type
Native Body schema for Native Body DataHandler BytesMessage BytesBody Byte array
Same as first row MapMessage MapBody Set of name/value pairs addressed by name. Value is a simple Java™ type.
Same as first row Message BaseBody None (empty)
Same as first row ObjectMessage ObjectBody Serialized Java object
Same as first row StreamMessage StreamBody Stream of simple Java types
Same as first row TextMessage TextBody Java String

Note that if the operation name is not set, it will be derived from the type of incoming message as determined by this table:

Default behavior if an operation name is not set

Message type Operation name
BytesMessage handleBytes
MapMessage handleMap
ObjectMessage handleObject
StreamMessage handleStream
TextMessage handleText
Message handleBase

If the operation name returned by the function selector has not been configured for the export, an exception will be thrown.



Prepackaged JMS function selectors

Several JMS function selectors come with BPM.

The following prepackaged JMS function selectors can be used for your services.

Note that selections are filtered. If you only had one operation on an interface, for example, then the one operation function selector would be available.

Prepackaged function selectors

Function selector Description
JMS function selector for simple JMS data bindings This function selector follows the JMS standard of defining a message class with five subclasses for the body or payload which contains the message itself. Each subclass has a different body type. This function selector uses the JMSType property of the message to select the operation name.
JMS header property function selector The default function selector returns the value of the JMS String Property, TargetFunctionName, from the header. To identify the JMS, MQ JMS or generic JMS messages, the default behavior is for the import to set the JMS header property, TargetFunctionName, to the name of the interface operation name, and the default function selector used by the export extracts the TargetFunctionName property from the JMS header to correctly identify the incoming message.

This function selector is used within an SCA context as it is using XML in the message body, so it could be used in a module to module scenario.

It is configurable with a data handler. You can specify the JMS header property used to do the map. By default, the header property is a user-defined one: TargetFunctionName.

JMS service gateway function selector This function selector should be used in conjunction with a binding using the service gateway interface. It determines if the request is a one-way or two-way operation by examining the JMSReplyTo property set by the client.
One operation function selector This function selector returns the one single operation on the interface.

These function selectors are discussed in more detail in JMS, MQ JMS and generic JMS function selector.



Related reference:

Overview of JMS function selectors


Prepackaged JMS and MQ fault selectors

Fault selectors handle runtime exceptions. Some fault selectors come ready to use with the JMS, MQ JMS, generic JMS and MQ bindings.

You can configure your import and export bindings to handle faults ( business exceptions) that occur during processing. A fault handler can be set up at three levels: you can associate a fault handler with a fault, with an operation, or with a binding. For import bindings, you can also set up a fault selector to determine whether a response is a fault and, if so, the name of the fault. See Handling faults in bindings for more information.

Prepackaged JMS and MQ fault selectors

Fault selectors Description
Header-based fault selector A header-based fault selector examines the headers in the incoming response message to determine if the response message is a business fault, a runtime exception or a normal message.

See Header-based fault selector.

SOAP fault selector A SOAP fault selector examines the body of the incoming response message for the fault message and examines the SOAP header to determine if the fault is a business or runtime fault, and the fault name in the case of a business fault.

See SOAP fault selector.

You can also create a new fault selector resource configuration.




Related concepts:

Prepackaged JMS data format transformations

JMS function selectors

Prepackaged MQ data format transformations

Prepackaged MQ function selectors


Related reference:

Overview of JMS, MQ JMS and generic JMS bindings

Data handlers

Work with the simple JMS data bindings

Business object XML using JMS text message serialization

Overview of MQ data format transformations

Overview of the MQ function selectors


Create applications with JMS bindings

Building applications that use the JMS bindings are shown in this section.



Create a JMS import to communicate with a JMS client

You might want to connect your service-oriented architecture (SOA) application to an existing JMS client. In this task, we will take you step by step through the steps necessary to do this.

Prerequisite: The JMS administered objects are configured for the JMS Client and known. In addition, there should be a module that contains your service-oriented architecture application. The message format expected by the JMS client is also known

  1. In order for your SOA application to communicate to an existing JMS client, have created a business object and an interface that would represent your JMS client application in an SOA manner. Mapping a message to an SCA interface provides guidance on how to create such a business object and interface.
  2. Create a component that will enable your existing SOA application to communicate to the existing JMS client application.


+

Search Tips   |   Advanced Search