Network Deployment (Distributed operating systems), v8.0 > Develop and deploying applications > Develop SCA composites > Specify bindings in an SCA environment


Configure the SCA JMS binding

We can configure the Service Component Architecture (SCA) JMS binding for services and references to support messaging between SCA applications and JMS providers.

Use the administrative console to enable the SIB service and Configuration reload enabled option on the application server where the application runs. Restart the server to enable the dynamic reloading of the SIB configuration files for this server. See the SIB service settings information to learn more about enabling the SIB service.

When you use the JMS binding, it is important that you follow best practice guidelines on design, configuration, and tuning of the messaging topology. Following these guidelines is especially important when you design systems for high throughput or high availability. Read the documentation on using JMS bindings in this information center, specifically "Multiple-server bus with clustering." The developerWorks articles "Configuring and tuning WebSphere MQ for performance on Windows and UNIX" and "Performance tuning for Java Messaging Service on WAS on z/OS" also provide useful information.

Bindings determine how a component communicates with the world outside its domain. SCA services use bindings to describe the access mechanism that clients must use to call the service. SCA references use bindings to describe the access mechanism used to call a service.

Use the SCA JMS binding, you can make SCA components available over JMS or you can use existing JMS applications within an SCA environment. We can use the SCA JMS binding element, <binding.jms>, within either a component service or a component reference definition. When a JMS binding is applied within a component service interface definition, the JMS binding enables clients to access an SCA service that is offered by a JMS provider. When the JMS binding is applied on a component reference, the SCA component can consume an external JMS application or another SCA component using JMS.

WAS supports asynchronous messaging using JMS. The default messaging provider enables enterprise applications deployed on WAS to perform asynchronous messaging without the need for you to install a JMS provider. The default messaging provider is installed and runs as part of WAS. The product supports the default messaging provider or WebSphere MQ as the messaging engine.

The SCA JMS Binding specification describes the <binding.jms> binding element and available attributes and options.

To learn more about the <binding.jms> binding element, see the SCA JMS Binding specification documentation.

SCA with JMS supports the following messaging exchange patterns:

A request is a message that is sent to an SCA service or sent by an SCA reference. A response is a message that is received back at a reference or a message that is sent by a service in response to a previous request message. In SCA, a response is always a reply to a previous request. In a one-way message, a request message is sent and a response is not expected.

This task describes the steps necessary to enable SCA applications for JMS using request-response or one-way messaging.


Procedure

  1. Identify the SCA business-level application that you want to enable for JMS messaging.

  2. Identify and configure the JMS resources for your SCA application.

    We can configure JMS resources for the default messaging provider before deployment of the SCA application. During deployment of the SCA application, the product dynamically creates any JMS resources that the JMS binding needs that do not exist.

    SCA applications are bound to JMS resources through their binding definitions in a corresponding composite definition file. The composite definition file for JMS uses Java Naming and Directory Interface (JNDI) names to identify JMS administered objects that are used by the SCA runtime environment on behalf of the SCA application to provide access over the specified binding.

    We can configure the following JMS resource references in the JNDI directory or choose for the product to dynamically create the resources for you:

    • a service integration bus
    • a request queue and a response queue. A response queue is only required for request-response messaging. The physical queues and the logical queues must be defined.
    • an activation specification to handle the request to the service
    • a connection factory to process the response

    To learn more about manually creating JMS resources, see the documentation on JMS resources for the default messaging provider. To learn more about dynamically creating JMS resources, see the dynamic JMS resource creation during deployment information.

  3. Configure an SCA service with the SCA JMS binding.

    To expose an SCA service over the JMS binding, add the <binding.jms> element within the service definition.

    Within the <binding.jms> element, define the following:

    • an <activationSpec> element to identify the activation specification that the binding uses to connect to a JMS destination to process request messages
    • a response <connectionFactory> element for request-response messaging patterns
    • a response <destination> element that describes the JMS destination for responses from the JMS binding. Specifying the response destination is optional because the runtime environment obtains the JMSReplyTo destination that is set on the incoming request message to determine the response destination. If the JMSReplyTo attribute is not set on the request message, the response <destination> element is used to identify the response destination. This element is not applicable for one-way messaging patterns.

  4. Configure an SCA reference with the SCA JMS binding.

    To consume or expose a JMS application or SCA reference with the JMS binding, add the <binding.jms> element within the SCA reference definition.

    Within the <binding.jms> element, define the following:

    • a <connectionFactory> element to identify the JNDI name of the connection factory used to process messages sent from the reference to the referenced service
    • a <destination> element to identify the JMS queue or topic used to send messages to the referenced service
    • a response <destination> element that describes the JMS destination queue used to process responses from the JMS binding. This element is optional for request-response messaging and not applicable for one-way messaging

  5. Optional: Configure JMS message correlation.

    We can optionally configure a JMS correlation identification for a request message and its response. Because of the asynchronous nature of JMS, it is important to determine if message correlation is required. A request-response messaging pattern is not equivalent to synchronous messaging.

    We can use the @correlationScheme element to identify the correlation scheme used when sending a reply or callback messages. The valid values for this element are: RequestMsgIDToCorrelID, RequestCorrelIDToCorrelID, and none. The default value is RequestMsgIDToCorrelID.

    To configure JMS message correlation, you can specify a correlationID element within the composite definition file used within the JMS header to link two messages.

  6. Optional: Invoke an operation using JMS operation selection

    Use the @nativeOperation attribute in a composite definition, the application can override operation selection; for example:

    <service>
    <binding.jms>   ...
    
    <operationProperties
          name="operationToInvoke"
          nativeOperation="selectedOperation"/>   ...
    
    </binding.jms>
    </service> 

    In this example, when the configured operation selector selects the operation named selectedOperation, the run time invokes operation operationToInvoke on the target service implementation. The overriding occurs whether the service binding is configured using default JMS operation selection, JMS user property operation selection, or a JMS custom selector.


Results

You have defined the JMS resources you need for your SCA application, configured the SCA JMS binding for your SCA services and references, and deployed the application. Your application is now ready for use.


Example

The following example illustrates two SCA component implementations and the use of request-response and one-way messaging.

Figure 1. SCA JMS binding example

The HelloService component implementation illustrates the request-response message pattern. This HelloService component exposes the service interface with the name, getGreeting, used to illustrate a return response of hello plus the value of getGreeting.

The LoggingService component implementation is a logging service. This component exposes a one-way service interface with the name, log, that receives a message and logs the message in a repository.

The HelloService has an SCA reference to the LoggingService. Each time the HelloService service receives a message, it calls the LoggingService service to log the message.

In this example, a Thin Client for JMS application sends a message, formatted as a JMS ObjectMessage message type to the SCA HelloService using the jms/SCA_sample_Request queue. The ObjectMessage sets the scaOperationName property to the value, getGreetings. The HelloServiceComponent receives the message over the JMS HelloService binding. The HelloServiceComponent then sends a request to the referenced service, LoggingService, and the one-way operation is complete. HelloServiceComponent sends a response of hello plus the value of getGreetings to the client application using the jms/SCA_sample_Response queue to complete the request-response operation.

Configure an SCA JMS binding for a request-response service from a JMS client to SCA service

The following example describes a <binding.jms> element within the component definition file for a request-response message exchange pattern from a JMS client to an SCA service:

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
  targetNamespace="http://www.ibm.com/soa/sca/samples"
   xmlns:hw="http://www.ibm.com/soa/sca/samples"
  xmlns:ts="http://tuscany.apache.org/xmlns/sca/1.0"
   name="HelloServiceComposite">

<component name="HelloServiceComponent">
<implementation.java class="soa.sca.samples.jms.HelloServiceImpl"/>
<service name="HelloService"> 
<interface.java interface="soa.sca.samples.jms.HelloService"/>   
<binding.jms>     
<destination name="jms/SCA_sample_Request" type="queue"/>     
<activationSpec name="jms/SCA_sample_AS"/>     
<response>        
<destination name="jms/SCA_sample_Response" type="queue"/>        
<connectionFactory name="jms/SCA_sample_CF"/>     
</response>     
<ts:wireFormat.jmsObject/>  
</binding.jms>

</service>

</component>


</composite> 

The following example describes a <binding.jms> element within the component definition file for a one-way interaction from one SCA service to another SCA service. The <binding.jms> binding definition is similar to the HelloService; however, because the message operation is one-way, there is not a response definition.

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
  targetNamespace="http://www.ibm.com/soa/sca/samples"
  xmlns:hw="http://www.ibm.com/soa/sca/samples"
  xmlns:ts="http://tuscany.apache.org/xmlns/sca/1.0"
  name="HelloServiceComposite">

<component name="LoggingService">
<implementation.java class="soa.sca.samples.jms.LoggingServiceImpl"/>

<service name="LoggingService">
<interface.java interface="soa.sca.samples.jms.LoggingService"/>   
<binding.jms>
    
<destination name="jms/SCA_Logging_Request" type="queue"/>     
<activationSpec name="jms/SCA_sample_AS"/>     
<ts:wireFormat.jmsObject/>
  
</binding.jms>

</service>


</component>
</composite> 

Configure an SCA JMS binding for two-way service from a JMS client to SCA reference

The following example describes a <binding.jms> element within the component definition file for a request-response message exchange pattern from a JMS client to an SCA reference:

SCA reference

<reference name="helloWorldService">
<interface.java interface="my.HelloWorldService"/>  
<binding.jms>      
<connectionFactory name="jms/helloWorldServiceCF"/>      
<destination name="jms/HelloWorldService"/>      
<response>          
<destination name="jms/SCA_sample_Response"/>      
</response>   
</binding.jms>
</reference>


What to do next

Based on your business needs, you can configure an SCA JMS binding wire format or configure transactions for the SCA JMS binding.

Explore the JMS binding samples to better understand how to invoke an SCA component service using a JMS client. For information on JMS samples, see "SCA samples." To download JMS binding samples from a product website:

  1. Go to the Samples, v8.0 information center.

  2. On the Downloads tab, click FTP or HTTP in the Service Component Architecture section.

  3. In the authentication window, click OK.

  4. From the SCA.zip compressed file, download the SCA/JMS directory and follow instructions in SCA/JMS/documentation/readme.html to build the files.

    Instead of building deployable files, you can use the prebuilt jms-callback-service.jar, jms-twoway-oneway-service.jar, and jms-twoway-service.jar files in the SCA/installableApps directory of the compressed file.

After you obtain your SCA components, deploy the components in an application and test the JMS binding.


Related


Configure SCA JMS binding wire formats
Configure transactions for the SCA JMS binding
Dynamic JMS resource creation during deployment
Invoke operations using JMS binding operation selection
Invoke operations using JMS user property operation selection
Invoke operations using custom operation selectors
Multiple-server bus with clustering
Samples, v8.0 information center
Specify bindings in an SCA environment
Deploy and administering business-level applications
Configure resources for the default messaging provider
Use JMS to connect to a WAS default messaging provider messaging engine
Use JMS resources with the Thin Client for JMS with WAS
Tune messaging


Related


Default messaging
SIB service [Settings]
Service Component Architecture specifications and APIs
Configure and tuning WebSphere MQ for performance on Windows and UNIX
Performance tuning for Java Messaging Service on WAS on z/OS

+

Search Tips   |   Advanced Search