Configuring the SCA Web service binding

You can expose a Service Component Architecture (SCA) application as a Web service by configuring the SCA Web service binding.

About this task

Web services technology plays an important role in most service-oriented architecture (SOA) solutions relevant today, including SCA. The Web service binding type enables SCA applications to expose services as Web services to external clients as well as enabling SCA components access to external Web services. External clients that access SCA services exposed as Web Services might or might not be implemented as an SCA component. You can use the Web service binding element <binding.ws> within either a component service or a component reference definition. When this binding is used with a component service, the Web service binding type enables clients to access a service that is offered by a particular component as a Web service. In the case where the Web service binding is used with a component reference, components in an SCA composite can consume an external Web service and access it just like any other SCA component.

The Feature Pack for SCA supports Web Services Description Language (WSDL) Version 1.1 definitions that also conform to the WS-I Basic Profile Version 1.1 and Simple SOAP Binding Profile 1.0 standards, and use the document literal style. All these conditions are required for support.

The SCA Web service binding applies to the services and references of components. The Web service binding defines the manner in which a service is made available as a Web service, and in which a reference can invoke a Web service. This binding is a WSDL-based binding; meaning that the binding either references an existing WSDL document or enables you to specify enough information to generate a WSDL document.

You can typically use the same policy set functionality, that you use for defining qualities of service on JEE-based Web services that are running in the application server, to define quality of service definitions on SCA clients and services that use the SCA Web Service binding. When the instructions for administratively configuring these policy set definitions are different for SCA-based Web services, than they are for JEE-based Web services, then special articles and instructions are provided in this information center. If there are no special instructions for SCA, configure the corresponding quality of service on the SCA-based Web service the same way that you would configure that quality of service for a JEE-based Web service.

Supported configurations Supported configurations: The SCA Web service binding provides support for providing and consuming services using the SOAP Version 1.1 over HTTP and SOAP V1.2 over HTTP protocols.sptcfg
Supported configurations Supported configurations: The Feature Pack for Service Component Architecture (SCA) does not support the following functions:
  • Java API for XML-Based Web Services (JAX-WS) handlers when using the SCA Web service binding
  • Message Transmission Optimization Mechanism (MTOM) or SOAP with Attachments (SwA) binary message optimizations
Use the SCA Web service binding without implementing JAX-WS handlers. Do not use SwA binary message optimizations or MTOM optimizations for transferring binary data between SCA clients and services that use the SCA Web service binding. Instead of implementing MTOM or SwA binary message optimizations to send binary data, use the base64Binary XML Schema Definition (XSD) encoding to embed the data within the SOAP message.sptcfg

Procedure

Results

You have a configured SCA Web service binding service or reference.

Avoid trouble Avoid trouble: There are additional ways for the Web service binding function to generate a WSDL port that are not described in this topic. However, these additional methods that rely on WSDL generation at run time add dependencies on the runtime environment that can cause problematic results.

For an example that is not problematic, suppose you write a service using the bottom-up style, starting from a Java interface, and deploy the service with an empty element. This directs the runtime environment to generate the WSDL port for this service. Also suppose an SCA client is developed with access to the original Java classes used to write the service implementation. This SCA client is used to test the SCA service using a client-side reference with Web service binding. You can configure this reference without any knowledge of the service WSDL. In this case, the reference interface is the original Java interface of the service, and you can resolve the reference using the <reference> @target mechanism. See the resolving SCA references documentation for more information on using the <reference> element to resolve an SCA reference using the @target attribute. Using this approach, there is no WSDL to obtain or refer to in constructing the client. This works because the Feature Pack for SCA runtime environment maps the service-side Java to WSDL in an identical manner as it maps the client-side Java to WSDL.

In contrast, the following scenario is problematic. Suppose that you write an SCA client with a Web service binding reference to a Web service that is hosted on a platform other than the Feature Pack for SCA. It might seem reasonable to generate your Java client from the service provider, and then ignore the WSDL from that point on, avoiding the additional syntax in your client-side composite definition. To do this, you use the <binding.ws> element @uri attribute to specify the endpoint URL where the service is hosted. This scenario is problematic because it forces the runtime environment to generate a WSDL port for the client which might result in subtle mismatches between the WSDL generated for the client side and the actual WSDL port description of the deployed Web service.

You can avoid these potential problems by ensuring that client package references the original WSDL obtained from a Web service provider. If you use the shortcut of omitting a client-side reference to the WSDL, be sure to do so only in the case when you are sure the WSDL port that is generated for the client is identical to the WSDL port of the deployed service because the service port is generated using the same algorithm.

gotcha

What to do next

Deploy your composite that has the SCA Web service binding service or reference.

Avoid trouble Avoid trouble: If the composite uses a bidirectional interface as an SCA service interface and a NullPointerException results when you add your SCA module or application to a business-level application (for example, using the wsadmin AdminTask.addCompUnit command), you might need to add the SCA @Callback annotation to the forward Java interface.

A NullPointerException can occur whether you are using a top-down development style (starting from WSDL or XSD) or a bottom-up style (starting from Java). With the top-down style, a composite definition typically includes a bidirectional interface definition such as the following:

<interface.wsdl interface="http://forward.my/intf#wsdl.interface(ForwardIntf)"
    callbackInterface="http://callback.my/intf#wsdl.interface(CallbackIntf)"/>

With the bottom-up style, a composite definition typically includes a bidirectional interface definition such as the following:

<interface.java interface="my.forward.intf.ForwardIntf"
    callbackInterface="my.callback.intf.CallbackIntf"/>

The NullPointerException can occur if the forward Java interface is not annotated with @Callback, or more specifically @org.osoa.sca.annotations.Callback. In the top-down example, the forward Java interface is the class generated from portType, http://forward.my/intf/ForwardIntf using the wsimport tool or my.forward.intf.ForwardIntf if the default options are used. In the bottom-up example, the forward Java interface is the class my.forward.intf.ForwardIntf.

To fix the NullPointerException problem, add the @Callback annotation to the forward Java interface and recompile. The @Callback annotation is a class-level annotation with a single argument, the callback interface Class object; for example:

...
import org.osoa.sca.annotations.Callback
@Callback(my.callback.intf.CallbackIntf.class) 
public interface ForwardIntf  {
...

If you are using the recommended top-down development style, the forward Java interface is a generated class. It is generated from the WSDL portType using the wsimport tool. Use the -s or -keep option so that wsimport generates the Java source files, and then add the @Callback annotation manually to the generated class and recompile.

gotcha



In this information ...


IBM Redbooks, demos, education, and more

(Index)

Use IBM Suggests to retrieve related content from ibm.com and beyond, identified for your convenience.

This feature requires Internet access.

Task topic Task topic    

Terms and conditions for information centers | Feedback

Last updatedLast updated: Jan 16, 2013 3:37:33 AM CST
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=v700osgijpa&product=was-nd-mp&topic=tsca_scawebservices_binding
File name: tsca_scawebservices_binding.html