This topic applies only to the IBM Business Automation Workflow Advanced configuration.

JAX-WS data handler

Edit online

The Enterprise JavaBeans (EJB) import binding uses the JAX-WS data handler to turn request business objects into Java™ object parameters and to turn the Java object return value into the response business object. The EJB export binding uses the JAX-WS data handler to turn request EJBs into request business objects and to turn the response business object into a return value.

This data handler maps data from the SCA-specified WSDL interface to the target EJB Java interface (and vice versa) using the Java API for XML Web Services (JAX-WS) specification and the Java Architecture for XML Binding (JAXB) specification.
Note: Current support is restricted to the JAX-WS 2.1.1 and JAXB 2.1.3 specifications.
The data handler specified at the EJB binding level is used to perform request, response, fault, and runtime exception processing.
Note: For faults, a specific data handler can be specified for each fault by specifying the faultBindingType configuration property. This overrides the value specified at the EJB binding level.

The JAX-WS data handler is used by default when the EJB binding has a WSDL interface. This data handler cannot be used to transform a SOAP message representing a JAX-WS invocation to a data object.

The EJB import binding uses a data handler to transform a data object into a Java Object array (Object[]). During outbound communications, the following processing takes place:
  1. The EJB binding sets the expected type, expected element, and targeted method name in the BindingContext to match those specified in the WSDL.
  2. The EJB binding invokes the transform method for the data object requiring data transformation.
  3. The data handler returns an Object[] representing the parameters of the method (in the order of their definition within the method).
  4. The EJB binding uses the Object[] to invoke the method on the target EJB interface.
The binding also prepares an Object[] to process the response from the EJB invocation.
  • The first element in the Object[] is the return value from the Java method invocation.
  • The subsequent values represent the input parameters for the method.

This is required to support the In/Out and Out types of parameters.

For parameters of type Out, the values must be returned in the response data object.

The data handler processes and transforms values found in the Object[] and then returns a response to the data object.

The data handler supports xs:AnyType, xs:AnySimpleType, and xs:Any along with other XSD data types. To enable support for xs:Any, use the @XmlAnyElement (lax=true) for the JavaBeans property in the Java code, as shown in the following example: 
public class TestType {
	private Object[] object;

	@XmlAnyElement (lax=true)
	public Object[] getObject() {
		return object;
	)

	public void setObject (Object[] object) {
		this.object=object;
	)
)
This makes the property object in TestType an xs:any field. The Java class value used in the xs:any field should have the @XmlAnyElement annotation. For example, if Address is the Java class being used to populate the object array, the Address class should have the annotation @XmlRootElement.
Note: To customize the mapping from the XSD type to Java types defined by the JAX-WS specification, change the JAXB annotations to fit your business need. The JAX-WS data handler supports xs:any, xs:anyType, and xs:anySimpleType.
The following restrictions are applicable for the JAX-WS data handler:
  • The data handler does not include support for the header attribute @WebParam annotation.
  • The namespace for business object schema files (XSD files) does not include default mapping from the Java package name. The annotation @XMLSchema in package-info.java also does not work. The only way to create an XSD with a namespace is to use the @XmlType and @XmlRootElement annotations. @XmlRootElement defines the target namespace for the global element in JavaBeans types.
  • The EJB import wizard does not create XSD files for unrelated classes. Version 2.0 does not support the @XmlSeeAlso annotation, so if the child class is not referenced directly from the parent class, an XSD is not created. The solution to this problem is to run SchemaGen for such child classes.

    SchemaGen is a command line utility (located in the WPS_Install_Home/bin directory) provided to create XSD files for a given bean. These XSDs must be manually copied to the module for the solution to work.