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


Configure the SCA web services binding

We can expose a Service Component Architecture (SCA) application as a web service by configuring the SCA web services binding.

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 and gives 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. We 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. If the web service binding is used with a component reference, components in an SCA composite can consume an external web service and access it like any other SCA component.

The product supports 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 services 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 Java EE-based web services, then special topics 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 Java EE-based web service.

The SCA web services binding provides support for providing and consuming services using the SOAP v1.1 over HTTP and SOAP V1.2 over HTTP protocols.

The product does not support the following functions:

Use the SCA web services 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 services 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.


Procedure


Results

You have a configured SCA web services binding service or reference. 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. We 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 about 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 product 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 product. 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.


What to do next

Deploy your composite that has the SCA web services binding service or reference. 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.


Related


Configure web service binding custom endpoints to support a proxy server
Configure the SCA web services binding to transport SOAP messages over JMS
Web services policy sets
SCA components
SCA composites
SCA domain
Specify bindings in an SCA environment
Resolve SCA references
Develop SCA services with existing Java code
Manage policies in a policy set
Deploy and administering business-level applications
Develop SCA service clients
Manage policy sets
Export WSDL and XSD documents using scripting
wsimport command for JAX-WS applications


Related


Service Component Architecture specifications and APIs

+

Search Tips   |   Advanced Search