This article, Part 5 in a series on the IBM WebSphere Application Server V7 Feature Pack for SCA, describes details of the SCA bindings that are provided by the feature pack, specifically the default binding, Web Services binding, and EJB binding. These SCA (Service Component Architecture) bindings are used to define the transport/protocol access mechanism for remote services and references. Bindings encapsulate all the configuration and policy data, thereby insulating the application from these details. Bindings are specified on remotable SCA services and on each reference.
See Part 1 of this series for an overview of SCA bindings within the SCA assembly model.
Services and references enable a component to communicate with other applications. By design, however, they say nothing about how that communication happens. Bindings perform the job of specifying this communication.
A binding specifies exactly how communication should be accomplished between an SCA component and its service consumers and providers. Depending on what relationship the components have with the services they are providing or using, a component might or might not have explicitly specified bindings. In Figure 1, which shows how SCA integrates intents and policies, a component that communicates with another component in the same domain -- even one in another process or on another machine -- need not have any explicit bindings specified. Instead, the SCA runtime determines what bindings to use, freeing the developer from this chore.
Figure 1. Binding overview
To communicate outside its SCA domain, whether to a non-SCA application or an SCA application running in some other SCA domain, a component must specify one or more bindings for this communication. Each binding defines a particular protocol that is used to communicate with the service or reference. A single service or reference can have multiple bindings, enabling different remote software to communicate with it in different ways.
Know that an SCA application communicating with another SCA application in a different domain does so using a specific protocol (like Web services) and therefore views that application just like a non-SCA application; its use of SCA isn’t visible outside its domain. This demonstrates a proper separation of concerns between the service consumer and provider implementation; neither SCA application needs to know about the details of their implementation; just how to communicate with each other.
As shown in the Figure 1, a binding specifies exactly how communication should be accomplished between an SCA component and its consumer or provider. A binding can be configured as an access mechanism offered by a service or requested by a reference. Examples of binding include:
- SCA default binding
- Web service
- Stateless session EJB.
References use bindings to describe the access mechanism used to invoke a service (which can be a service provided by another SCA component). Services use bindings to describe the access mechanism that consumers (which can be a client from another SCA component) must use to call the service. In general, SCA enables each remotable service and each reference to specify the protocols it supports using bindings. A service or reference can be configured with multiple bindings.
Bindings that are not chosen by the runtime for intra-domain communication are defined explicitly in the component’s composite configuration file. It is interesting to note that specific bindings cannot be specified directly in a Java™ implementation. (The SCA Java Component Implementation V1.00 Service Component Architecture Specifications, Version 1.0 does not define any way for you to specify a binding directly in Java.)
Here's an example of how a binding for a given component's reference might be specified:
Listing 1. Sample reference binding
<reference name="StockQuoteService"> <interface.java interface="services.stockquote.stockquoteService"/> <binding.ws uri= http://www.sqs.com/StockQuoteService requires="soap/1.2"/> </reference> ..
In this example, the binding element specifies two things:
- What protocol the binding uses.
- The URI where the service can be accessed using this protocol.
The binding.ws in the element's name indicates the first of these, specifying the Web services binding. The element's URI attribute indicates the second item, specifying the URL at which the service can be found. It is also possible and much more likely for a Web service binding to use a relative URL rather than the absolute form shown here.
Therefore, a binding is defined by a binding element in the composite file, which itself is a child element of a service or of a reference element to which it pertains. The binding element is formally described by SCDL such that the form is similar for all binding elements.
Figure 2. Usefulness of bindings
As mentioned earlier, bindings make it possible for the choice of protocol to be independent from application programming interface. Think of how applications use different protocols in Java EE 5 and its J2EE™ predecessors. Each protocol is provided by a distinct technology, so each one has its own application programming interface. For example, using SOAP over HTTP typically means building on JAX-WS (or JAX-RPC in J2EE 1.4). Using IIOP typically means using EJB components. This approach mixed business logic with protocol selection.
SCA takes a simpler approach. Rather than wrapping different protocols into distinct technologies with different APIs, SCA enables each remotable service and each reference to specify the protocols it supports using bindings that have been abstracted out of the implementation. The programming model seen by the application remains the same regardless of which protocol is used. This enables replaceability of bindings and binding configuration during deployment without affecting the business logic -- in fact, this improves the reusability of the business logic.
For example, to be accessible via SOAP over HTTP, an SCA service can use the Web services binding. Similarly, the EJB session bean binding enables access to session beans using the Internet Inter-ORB Protocol (IIOP).
SCA defines several different types of bindings, including Web service, stateless session EJB, JMS, JCA, SCA default binding, and so on. However, the initial release (Version 1.0) of the Feature Pack for SCA included support for the default (SCA) binding, Web service binding, and EJB 2 and EJB 3 bindings. The latest release (Version 1.0.1) includes support for the JMS binding. These bindings are discussed in more detail in the next sections.
Every SCA runtime provides the SCA binding, also known as the default binding, meaning that it’s the binding used when no other binding is specified for a component reference or service. It is the natural binding to use for SCA-to-SCA invocations such as an SCA client invoking an SCA service.
The protocol this binding uses is determined by each SCA runtime and is therefore only available between SCA consumers and providers that are deployed in the same SCA domain. By architecture, the domain concept is left to each vendor to design and, therefore, domains are vendor specific -- meaning there isn’t an architected way to use a default binding to invoke or offer a service that is deployed in another domain. The SCA runtime in WebSphere Application Server V7 will choose the most efficient mechanism for invoking services based on deployment specifics (such as locality of reference), but it will honor semantic behavior (like pass by value) when invoking through remotable interfaces.
Figure 3. SCA domains and default binding
A domain represents an important ease of use concept in SCA. The domain represents a scope for which services can be assembled together using logical names. This has two important functions:
- It greatly simplifies the job of deploying SCA composites, since specifics about the configuration of the SCA domain do not need to be understood by the deployer.
- Infrastructural changes (such as applications being moved from server to server) can occur without the need to reconfigure an SCA assembly.
The SCA Web service binding defines the manner in which a service can be made available as a Web service, and the manner in which a reference can be made to invoke a Web service. This binding is designed to provide and consume SOAP-based, WS-I (interoperable) compliant Web services.
The Web service binding is a Web Services Description Language (WSDL) 1.1 based binding, which means that it either references an existing WSDL binding or enables the assembler to specify enough information to generate one during deployment.
The Web service binding element <binding.ws> can be used within either a component service or a component reference definition:
- When used with a component service, this binding type enables clients to access the SCA service as a standard Web service.
- When used with a component reference, this binding enables a component to consume an external Web service the same way it consumes any other service.
SCA Web service bindings can be further customized through the use of WebSphere Application Server policy sets.
Figure 4 shows the SCA composite definition for a composite named MyValueComposite. It contains a component definition for the MyValueComponent, which contains a reference to a stock quote service. The StockQuoteComponent offers a stock quote service. Both the service and the reference use a Web service binding. As a reminder, these services could also be made available and connected through other bindings as well, such as the SCA default binding.
Figure 4. Web service binding example
SCA contributions can be packaged without a WSDL document. Omit the wsdlElement attribute on binding.ws and you are not required to package a WSDL document with your contribution. In this scenario, any necessary WSDL documents will be generated dynamically at run time. Web service clients must specify an endpoint using a method other than the WSDL location attribute since a static WSDL does not exist. It is important to know that the service interface’s method arguments, return types, and exceptions must conform to JAX-WS and EJB specifications.
Typically, both the Web service client and service need to use the same WSDL, therefore if a service is deployed without a WSDL, the Web service can be queried using "? wsdl" appended to the service URL for a WSDL to use for client access.
Listing 2 shows how to specify a WSDL-less deployment for a service. For services with callback interfaces, specify only an empty <binding.ws> tag. The interface.java and an appropriate callbackInterface are required service elements.
Listing 2. WSDL-less deployment for a service
<?xml version="1.0" encoding="UTF-8"?> <composite xmlns="http://www.osoa.org/xmlns/sca/1.0" xmlns:wsdl="http://www.w3.org/2004/08/wsdl-instance" name="helloworldws" > <component name="HelloWorldServiceComponent"> <implementation.java class="helloworld.HelloWorldImpl"/> <service name="HelloWorldService"> <interface.java interface="helloworld.HelloWorldService" callbackInterface="helloworld.HelloWorldCallback"/> <binding.ws/> <callback> <binding.ws/> </callback> </service> </component> </composite>
Listing 3 shows how to specify a WSDL-less deployment for a reference. This example shows how to specify an absolute service endpoint URL in the <binding.ws> URI attribute. For references with callback interfaces, specify only an empty <binding.ws>. The interface.java and an appropriate callbackInterface are required reference elements.
Listing 3. WSDL-less deployment of a reference
<?xml version="1.0" encoding="UTF-8"?> <composite xmlns="http://www.osoa.org/xmlns/sca/1.0" xmlns:system="http:// tuscany.apache.org/xmlns/system/1.0-SNAPSHOT" name="helloworldwsclient" > <component name="HelloWorldServiceClientComponent"> <implementation.java class="helloworld.HelloWorldServiceComponent"/> <reference name="HelloWorldService"> <interface.java interface="helloworld.HelloWorldService" callbackInterface="helloworld.HelloWorldCallback"/> <binding.ws uri="http://localhost:9080/HellowWorldServiceComponent/HelloWorldService"/> <callback> <binding.ws/> </callback> </reference> </component> </composite>
Listing 4 shows the use of a reference specifying the target attribute to resolve the service endpoint, as in <reference target="HellowWorldServiceComponent/HelloWorldService">. This is only applicable if the reference targets a service in the same SCA domain (WebSphere Application Server cell) as the reference.
Listing 4. Reference: ComponentName/Service
<?xml version="1.0" encoding="UTF-8"?> <composite xmlns="http://www.osoa.org/xmlns/sca/1.0" xmlns:system="http:// tuscany.apache.org/xmlns/system/1.0-SNAPSHOT" name="helloworldwsclient" > <component name="HelloWorldServiceClientComponent"> <implementation.java class="helloworld.HelloWorldServiceComponent"/> <reference name="HelloWorldService" target="HelloWorldServiceComponent/HelloWorldService"> <interface.java interface="helloworld.HelloWorldService" callbackInterface="helloworld.HelloWorldCallback"/> <binding.ws/> <callback> <binding.ws/> </callback> </reference> </component> </composite>
SCA feature pack and the WSDL document
The Feature Pack for SCA does not require you to provide a formal WSDL document to expose an SCA component as a Web service. This is useful for rapid service development when starting with a Java implementation that is going to be exposed as a Web service. Once the service has been developed and the service interface is complete, you should capture the service WSDL and use it as the formal definition of the interface. This ensures there is a proper respect for the formality of the interface in your SOA, and will help prevent making changes to services that could inadvertently break consumers of your new service.
Using WSDL documents
The two areas in which WSDL comes into play in the SCA feature pack so far are:
Defining a service interface
In defining a service interface, Java classes are derived from a WSDL by running the wsimport command in the WSDL to generate the Java interface and JAXB types. For a client, use these generated classes to type your proxy invocation (for example, along with @Reference). For a service, write a Java implementation that runs the generated interface (along with @Service, and so on). Listing 5 shows an example.
Listing 5. Define a service interface using a WSDL document
<wsdl:service name="BackEndComponentService"> <wsdl:port binding="intf:BackEndComponentServiceSoapBinding" name="BackEndComponentService"> <wsdlsoap:address location="http://localhost:9080/BackEndComp/BackEndComponentService"/> </wsdl:port> </wsdl:service>
Using Web services binding
You can develop SCA service clients that can both access and invoke an SCA service based on the SCA specification. An SCA client can consume a diverse set of services, such as enterprise beans, Web services, and other SCA services, through the capabilities of the respective SCA bindings, and by using the Plain Old Java Object (POJO) client programming model.
To develop SCA service clients, you can start with either an existing WSDL file, use the wsimport tool to generate the Java interface, or you can start with an existing Java interface. You can also develop a component that consumes or acts as a client of the target service using a component reference.
In addition to consuming a service from another component's reference, the Feature Pack for SCA also provides a mechanism for consuming an SCA service over the default binding from a non-SCA component. To do this, you will need to create a component definition using the Java implementation. In the SCDL file, you would add a <reference> element that refers back to the original interface and the field or setter of your SCA implementation. The reference is added as a child element of your component. The component is part of a composite definition.
Listing 6 shows a service client SCDL example. This example shows just one of several ways to specify binding.ws. You must package the WSDL definition and specify a wsdlElement=<namespace>#wsdl.port within the SCDL as shown.
Listing 6. Service client SCDL
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0" xmlns:dbsdo="http://tuscany.apache.org/xmlns/sca/databinding/sdo/1.0" name="FrontEndComponentComposite"> <component name="FrontEndComponent"> <implementation.java class="test.sca.bindings.ws.components.FrontEndComponentImpl"/> <reference name="aBackEndComponentServiceRef" target="BackEndComp/BackEndComponentService"> <interface.javainterface= "test.sca.bindings.ws.components.BackEndComponentService" callbackInterface="test.sca.bindings.ws.components.BackEndComponentCallback"/> <binding.ws wsdlElement="http://components.ws.bindings.sca.test#wsdl.port (BackEndComponentService/BackEndComponentService)"/> <callback> <binding.ws wsdlElement="http://components.ws.bindings.sca.test#wsdl.binding (BackEndComponentCallbackSoapBinding)"/> </callback> </reference> </component> </composite>
A <binding.ws> is ultimately defined in terms of a WSDL port, and this port can either be defined explicitly by a WSDL provided by the application developer, or defined implicitly, in which case the SCA runtime will generate the port for you. For example, if you do package a WSDL document with your client/service that defines a WSDL port, you could simply refer to it in SCDL on your <binding.ws/> definition.
You can configure a custom endpoint URI for SCA components that expose services over the Web service binding.
Typically, when a service is exposed over the SCA Web service binding, the service endpoint is specific to the server in which the service is hosted. Non-SCA clients use this endpoint URI to access the service. In some cases, you might want clients to indirectly reference the service by using a proxy server as the service endpoint. For example, a proxy server is required to implement clustered Web service binding endpoints. There are two ways to enable clients to use proxied endpoints:
- If your endpoints are specified in an SCA composite or WSDL document, you must ensure that the proxy endpoint is configured instead of the WebSphere Application Server specific endpoint.
- If your client resolves the endpoint by using the <sca:reference target=""> attribute in your client SCDL document, use the administrative console to configure the custom endpoints for SCA composites that are accessed by the HTTP protocol.
Here is an example that shows how to specify custom endpoints for making a service available over a proxy server:
- From the WebSphere Application Server administration console, navigate
to Applications => Application Types =>
Business-level applications => YourBLA =>
YourCU then click on Provide HTTP endpoint URL
information (Figure 5).
Figure 5. Specify custom endpoint
- On the next panel (Figure 6), choose one of the default URL prefixes
available, or specify a custom URL endpoint. The sample shown in the
figure is for the proxy server.
Figure 6. Provide HTTP endpoint URL information
This approach is the most flexible for SCA clients within the same domain as their service providers. When using the <sca:reference target=""> attribute, SCA references can be resolved to service endpoints without the client specifying endpoints in the SCDL or the WSDL document.
There are three ways for a client to obtain an endpoint for its service:
- binding.ws element in the component's composite configuration file
- WSDL port
- @target annotation
When target annotation (@target) is used, the endpoint used by the client is obtained from the SCA domain. This takes precedence over endpoints specified in WSDL or in the binding.ws element. Therefore, when using @target you do not need to specify any reference endpoints.
Clustered services are supported. When using clustered SCA services exposed as Web services, a WebSphere Proxy Server must be configured as with any other clustered Web service hosted by WebSphere Application Server. You must also configure WebSphere Proxy Server's endpoints for the endpoints used by SCA clients. This applies whether you specify client endpoints using @target, or whether you endpoints are specified on binding.ws or in the WSDL location attribute.
For the @target method, you need to specify the proxy endpoints in the WebSphere Application Server administrative console post-deployment of your services:
- In the admin console, navigate to the composition unit.
- In the Custom Http Endpoints URL text box, enter one secure and one non-secure HTTP endpoint that correspond to the endpoints on which your WebSphere Proxy Server is listening. The Proxy Server will then route the request to a specific application server that hosts your service.
- For binding.ws or WSDL-specified endpoints, enter the same base URI information (protocol, host, and port) that you entered in the Custom Http Endpoints text box. The key is that the endpoints need to be those of the Proxy Server.
The Feature Pack for SCA supports security policy on both services and references by integrating with the WebSphere Application Server policy set feature. WebSphere Application Server policy sets are defined through the administrative console and are given simple names. SCA policy sets are specified as XML qualified names. To mitigate this difference, the Feature Pack for SCA includes an extension that lets WebSphere Application Server policy sets be attached to SCA services and references. The extension is a global XML attribute called wsPolicySet, which is defined in a WebSphere-specific namespace (http://www.ibm.com/xmlns/prod/websphere/sca/1.0/2007/06). An example of how to use this attribute in the SCDL is shown in Listing 7. (The policySet attribute from the SCA Policy Framework specification is not supported in the Feature Pack for SCA.)
Listing 7. Example of wsPolicySets in SCDL reference
<reference name="EchoTimeServiceReferenceFromEchoClient"> <interface.java interface="test.ws.soa.sca.qos.policy.echoRealyServiceTest.echoService.EchoTimeService"/> <binding.ws wsdlElement="http://echoTime#wsdl.port(EchoTimeService/EchoTimeServiceSoapPort)" qos:wsPolicySet="WSHTTPS default" /> </reference>
Additionally, when using <reference target="">, the system-determined endpoints will honor a secure QoS policy on either the service or reference side, as shown in Listing 7. Listing 8, which shows how SSL policy is applied to the binding.ws service, addresses how qos:namespace is resolved. The key here is that the xmlns:qos attribute is used to specify the XML namespace, which contains the definition of the WebSphere wsPolicysSt extension attribute. The reference configuration is similar.
Listing 8. Example SSL policy on binding.ws service
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0" xmlns:wsdl="http://www.w3.org/2004/08/wsdl-instance" xmlns:qos=http://www.ibm.com/xmlns/prod/websphere/sca/1.0/2007/06 targetNamespace=http://www.ibm.com/samples/sca/wsusecase" name="EchoServiceWSComposite"> <component name="EchoServiceWSComponent"> <service name="EchoService"> <binding.ws qos:wsPolicySet="WSHTTPS default" qos:wsServicePolicySetBinding="Provider sample"/> </service> <implementation.java class="test.sca.bindngs.ws.components.EchoServiceImpl"/> </component> </composite>
Limitations of the Web service binding include:
- WSDL 2.0 is not supported, which implies that wsdl.endpoint is not supported.
- wsdlLocation is not honored and is currently ignored.
- Services cannot be exposed directly over binding.ws from components within composites used as implementations, nor promoted services. However, components that use composites as implementations might define a Web service binding for services it provides.
- Conversational interfaces are not supported for Web services bindings, or for any bindings.
- Multiple Web service bindings cannot be bound to the same service.
The EJB binding enables SCA to integrate with existing Java EE-based applications by exposing SCA services as stateless session beans. The EJB session bean binding enables you to treat previously deployed session beans as SCA services, by wiring them into an SCA composite as an SCA reference with the EJB binding. Figure 7 shows the EJB SCA binding used on both services and references.
Figure 7. EJB binding
An SCA service can be exposed as a session bean for consumption by Java EE applications. The binding element used within a component service or component reference for an EJB binding is <binding.ejb>.
Listing 9. Example using EJB binding element
<component name="HelloWorldServiceComponent"> <implementation.java class="helloworld.HelloWorldImpl"/> <service name="HelloWorldService"> <binding.ejb...ejb-version=/> </service> <reference name ="" > <binding.ejb ...> </ reference > </component>
The Feature Pack for SCA provides EJB binding support for both 2.x and 3.0 styles for service and references. Support is also provided for the reference target.
The service side EJB binding is available for JAR-packaged SCA applications only.
- EJB 2: SCA service is exposed through a stateless EJB for the consumption of EJB 2 clients. The stateless EJB for the service is bound to JNDI at ejb/sca/ejbbinding/<componentName>/<serviceName>.
- EJB 3: SCA service is exposed through a stateless EJB for the consumption of EJB 3 clients. The stateless EJB for the service is bound to JNDI at ejb/sca/ejbbinding/SOAAssureServiceComponentViaAny/SOAAssureServiceSCA#<package qualified SCA service interface with SUFFIX Remote or Local>
Reference side EJB binding is available for both JAR-packaged applications and WAR-packaged applications. The URI is used to lookup either EJB 2.x home or EJB 3.0 business interface, following the Java EE naming convention if you are wiring to an existing Java EE EJB module. If you wire to an SCA service with binding.ejb, then use these values:
- homeInterface: not used
- session-type: default value "stateless“
- ejb-version: default value "EJB2"
You can wire a reference to a service with an EJB binding, although this is not a typical use case. The EJB service binding exists primarily to expose the SCA component to pure Java EE clients or callers. An EJB reference binding can access a stateless EJB running in a pure Java EE environment.
The reference interface used with the EJB binding can be either a remote or local session bean interface. SCA deployment logic and the binding implementation will introspect the reference interface class to determine whether it is local or remote. If an SCA component needs to access both the local and remote interface of a session bean, then this should be modeled in the SCA assembly through two references, one with the local interface and one with the remote interface.
Before an SCA application starts in WebSphere Application Server, all EJB references and resource references defined in the application don’t need to be bound to the actual artifacts (enterprise beans or resources) defined in the application server. When defining bindings, you specify JNDI names for the referenceable and referenced artifacts in an application. The jndiName values specified for artifacts must be qualified lookup names.
You do not need to manually assign JNDI binding names for each of the interfaces or EJB homes on your enterprise beans in EJB 3.0 modules. If you do not explicitly assign jndiName bindings, the EJB container assigns default bindings.
Figure 8 shows an EJB reference binding consuming an EJB service inside a Java EE EAR file. The EJB reference binding provides access to a service offered by a stateless session bean.
Figure 8. Sample EJB reference binding
An SCA service is developed that will be called from a Java EE environment. Suppose you need to invoke the service from a Java EE environment that is not enhanced with SCA and therefore requires the use of the Java EE programming model. In this case, the SCA service is deployed into an SCA runtime that is capable of hosting the EJB binding (Figure 9).
Figure 9. Exposing SCA Service with an EJB Binding
Listing 10 shows an example of how the above service might be accessed as an EJB session bean.
Listing 10. Service in the SCA composite file (default.composite)
<service name="CompanyInfo"> <interface.java interface="com.app.jobbank.CompanyInfo"/> <binding.ejb ejb-version="EJB2"/> <reference>CompanyInfoComponent/CompanyInfo</reference> </service>
Since the client will use the standard Java EE programming model, the client needs to know the home interface of the SCA service. The service in the sca.composite file will appear as shown in Listing 11.
Listing 11. Client "lookup" code
JMS (Java Message Service) represents the Java interfaces for connecting to pervasive enterprise messaging backbones (like WebSphere MQ) and Enterprise Service Buses (like WebSphere ESB). SCA provides integration with services that are available via messaging through support of the OSOA JMS Binding V1.00 specification. Using SCA, new services can be made available over JMS, creating an open, implementation-neutral pathway to the service. As such, these services can reside on the enterprise messaging backbone or ESB, and, likewise, existing services available over JMS access paths can be the targets of SCA references.
Using the SCA JMS binding, you can compose and assemble SCA services that are available over JMS, or use existing JMS applications within an SCA environment. You can use the SCA JMS binding element <binding.jms> within either a component service or a component reference definition:
- When this binding is attached to the component service interface, the JMS binding enables client applications to access an SCA component through a JMS provider.
- When the JMS binding is used with a component reference, components in an SCA composite can consume an external JMS application and access it just like any other SCA component.
The default messaging provider is installed and runs as part of WebSphere Application Server. The JMS support in the Feature Pack for SCA supports the default messaging provider, and it supports the use of WebSphere MQ as the JMS provider.
The JMS binding enables SCA applications to utilize JMS access paths without requiring the business logic to understand messaging or message payload formats. Therefore, a simple POJO application can communicate over JMS by just configuring the JMS binding and corresponding JMS resources in SCDL without any messaging specific programming constructs, like a message driven bean.
The JMS binding design isolates the JMS resource configuration from the business logic in two ways:
- Specific resource configuration can be made in the SCDL.
- Specific JMS resources needed by the application can be dynamically configured as needed.
Figure 10. Configuring JMS binding on an SCA application
To configure a JMS binding on a simple SCA application:
- Identify the SCA business-level application that you want to enable for JMS messaging.
- 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, you must define the following:
- <activationSpec> element to identify the activation specification that the binding uses to connect to a JMS destination and process request messages.
- Response <connectionFactory> element for request-response messaging patterns.
- Response <destination> element that describes the JMS destination for responses from the JMS binding. This element is optional; the runtime obtains the JMSReplyTo destination from the incoming request message to determine the response destination. If the JMSReplyTo attribute is not set on the request message, this element is used to identify the response destination. (Not applicable for one-way messaging patterns.)
- (Optional) Identify and configure the JMS resources for your SCA
application. (Resources will be created dynamically if not
configured.) SCA applications are bound to JMS resources through their
binding definitions in their corresponding composite definition file.
The composite definition file for JMS uses JNDI (Java Naming and
Directory Interface) names to identify JMS administered objects that
are used by the SCA run time environment on behalf of the SCA
application. To use a JMS binding for SCA applications, you must
configure JNDI with references to the JMS resources defined in the
default messaging provider. Make sure that these JMS resource
references are created in the JNDI directory:
- Service integration bus.
- Request queue and response queue. A response queue is only required for request-response messaging. The physical queues and the logical queues must be defined.
- Activation specification to handle the request to the service.
- Connection factory to process the response.
- (Optional) Configure JMS message correlation.
- (Optional) Determine the operation to invoke using JMS binding operation selection.
- (Optional) Determine the operation to invoke using JMS user property operation selection.
- Deploy the SCA application.
If you are using WebSphere MQ as your JMS provider, all physical resources must be defined in using WebSphere MQ administration. Also, if you need to define a new service integration bus, you must restart WebSphere Application Server.
For the SCA JMS binding, the wire format is the format of the data in the JMS message that flows through the JMS provider. Because of the variety of message types and formats, SCA services and references that are configured with a JMS binding might require additional configuration so that the runtime environment can perform the marshalling and un-marshalling required to translate between application data formats and the format of the JMS message on the wire. Whether you are configuring an SCA service or reference, it is important to recognize if the wire format was previously established by your existing messaging application infrastructure, or if you are selecting the wire format along with your SCA application:
- If you are starting with an application that has a pre-existing messaging infrastructure and you are adding your SCA application to this environment, the wire format is likely already determined by the messaging infrastructure.
- If you are starting with an SCA application and you intend for this application to interact with future JMS message producers or consumers, you can specify the wire format within your SCA application.
If you have not determined the wire format, whatever you select here will effect how others wire to your services.
The SCA JMS binding supports transacting message delivery with the global transaction of a component. The SCA transaction policies are specified as intents that represent quality of service behavior offered by the JMS binding on an SCA service or reference. However, the SCA JMS binding does not propagate transaction context; therefore, the client and service cannot participate in the same global transaction.
SCA references can use the transactedOneWay intent to transact one-way requests. Services can use the transactedOneWay intent to transact one-way requests only or the exactlyOnce intent to transact both one-way and request-response message patterns.
- When the transactedOneWay intent is used on an SCA reference, a one-way request on the reference is not sent until the global transaction of the client is committed. If the global transaction of the client is rolled back, the request is not sent.
- When the transactedOneWay intent is used on an SCA service, a one-way request is received from the JMS binding as part of the global transaction of the client.
- When the exactlyOnce intent is used on a service, both one-way and request-response message patterns are received from the JMS binding as part of the global transaction of the client. The receipt of the message and the sending of the response for request-response messaging is not committed until the service transaction commits. If the service transaction is rolled back, the message is again made available for delivery or the message is sent to an exception destination that is based upon the configuration of the bus destination.
The SCA run time environment typically performs a rollback of a global transaction only if the component produces an unchecked exception error, which is a subclass of java.lang.RuntimeException or java.lang.Error class. A checked exception does not force a rollback. The component can force a rollback by using the UOWSynchronizationRegistry interface (Figure 11).
Figure 11. UOWSynchronizationRegistry interface
If a reference does not require a transactedOneWay intent, then one-way requests are sent immediately. If a service does not require the transactedOneWay or exactlyOnce intent, requests are removed from the queue prior to the delivery of the request to the component. If the component processing fails, these requests cannot be delivered again.
To configure transactions for the JMS binding:
- Specify the transactedOneWay or exactlyOnce intents on your SCA
service or reference to enable transacting message delivery with the
global transaction of your component. Figure 12 illustrates the use of
the transactedOneWay and exactlyOnce intents. In this example, the
TransactionalComponent component receives one-way and request-response
messages from the DataUpdate service and subsequently sends one-way
requests to the loggingService reference bt transaction. If the
component transaction rolls back, the active request is queued again
and any requests to the reference are not sent.
Figure 12. transactedOneWay and exactlyOnce intents
- Using the administrative console, configure the bus destination to handle failed messages. Navigate to Service integration => Buses => bus_name => Destinations => destination_queue_name or destination_topic_space_name.
- Under Exception destination, enter a value for the Maximum failed deliveries per message. This value specifies the maximum number of failed attempts to process a message, after which the message is forwarded from its intended destination to the exception destination. This property applies to individual messages.
The result of these steps is that you have updated your SCA composite to use transacted message delivery.
The Feature Pack for SCA dynamically creates the JMS resources necessary for an SCA composite, if those resources do not exist and relate to the WebSphere Application Server default messaging provider. WebSphere Application Server creates the resources with the default messaging provider when adding the SCA composite to a business-level application. It does not create resources that relate to WebSphere MQ; those resources must already exist.
The purpose of this support is to ease rapid development scenarios that require JMS resources. Having WebSphere Application Server create default resources also eases the developer’s administrative burden. Dynamic resource creation, however, is not a typical production scenario. A dynamically created SIBus resource is given a name that is specified in the JMS binding or, if the binding does not specify a resource name, is given a default name derived by the service name. When an SCA composite uses a mixture of existing and non-existing resources, WebSphere Application Server dynamically creates the resources that do not exist. In this way, the next time the application is deployed, the resources that were created the first time are reused for subsequent deployments.
Typical patterns for dynamic service resource creation include:
- Composite definition does not define resources.
- Composite definition defines destination and activation specification.
- Resources for both the destination and activation specification do not exist.
- The destination resource does not exist, but the activation specification resource exists.
- The destination resource exists, but the activation specification resource does not exist.
Services and references enable a component to communicate with other applications. By design, however, they say nothing about how that communication happens. Bindings perform the job of specifying this communication. The bindings supported in the IBM WebSphere Application Server Feature Pack for SCA are the default (or SCA) binding, the Web service binding, the EJB binding, and the JMS binding. By separating communication details from business logic, bindings can simplify the life of an SCA application developer.
in this series
Service Component Architecture Specifications
OASIS Open CSA technical committees
David Chappell and Associates
Software Components: Course-grained versus fine-grained
- Information Center:
EJB 3.0 bindings
Service Component Architecture
Chao Beck is a technical lead for the feature pack for Service Component Architecture (SCA) early program. She has long been a member of the Application Integration Middleware early programs team responsible for the execution of early programs for IBM WebSphere Application Server products. She handles the development and delivery of education for new product functions and the provision of customer support during pre-GA (early) programs and post-GA (customer acceleration) programs.
Mark Coats is a senior developer with WebSpere Application Server, whose focus is on Web services and the administrative console. In his earlier roles, he has been a developer on the CORBA object request broker and a communications systems engineer with Attachmate Corporation.