Generate service data object (SDO) facades for JAX-RPC Web services

 

+

Search Tips   |   Advanced Search

 

JAX-RPC 1.1 (JSR-101) defines the standard mapping of WSDL and Schema to Java in J2EE 1.4. The schema portion of the mapping does not support several common features of schema such as choices, substitution groups, simple type restrictions, and wildcards. JAX-RPC 1.1 requires that the unsupported schema types map to the Java SOAPElement type. Depending on the schema your WSDL file is built on, this may result in a Java Service Endpoint Interface programming model that requires extensive programming effort to deal with the SOAPElements.

You have the option of disabling the JAX-RPC schema to Java mappings that the wizards use by default and instead using the Java Eclipse EMF 2.2 SDO representation of XML Schema. This can be useful if your XML schema contains content that the JAX-RPC mappings do not handle gracefully. SDO facade generation is only supported for top-down Web services and Web service clients deployed to WebSphere® Application Server v6.0 and later.

If you want to create SDO facades when creating a top-down Web service or Web service client, the easiest way to generate SDO facades is to generate them while using the Web services wizards by enabling SDO facade generation in the preferences. If you have already created a Web service or client that uses the WebSphere JAX-RPC runtime with the Disable data binding and use SOAPElement option selected, you can generate the SDOs after the service or client has been created.

This method gives you the additional options of not copying the EMF 2.2 jar files into your EAR project which is only necessary if your Web service runs on WAS v6.0, and changing the package name for each namespace found in the schema.

 

Generating SDO facades using the Web services wizards

To have the Web services wizards generate SDOs when creating a top-down Web service or a Web service client, enable the

Disable data binding and use SOAPElement and

Generate SDO facades from Java classes preferences before running the appropriate wizard.

  1. Click

    Window > Preferences to open the Preferences window.

  2. Expand

    Web services | WebSphere | JAX-RPC Code Generation.

  3. On the WSDL2Java tab, select

    Disable data binding and use SOAPElement and

    Generate SDO facades from Java classes. Click OK. Note that you cannot generate SDO facades unless all types have been mapped to SOAPElements.

  4. Run the Web service or Web service client wizard as appropriate. On the first page of the wizard move the slider to at least the Deploy position because the SDO facades can only be generated if the deployment code is present.

 

Generating SDO facades manually

Before manually generating SDO facades, have created a Web service with the

Disable data binding and use SOAPElement option selected in the preferences. You can generate SDOs for top-down Web services and clients deployed to WAS v6.0 or later. This includes Web services and clients created with earlier versions of the Web services tools.

  1. Select the Java bean skeleton or Web service proxy Java bean, right-click and select

    Web services | Generate SDOs from Java.

  2. Select the location where the skeleton facade or proxy facade will be generated.

  3. Optionally you can select to copy the EMF 2.2. jar files to the EAR project. If you created your Web service or client with the WAS v6.0 runtime copy these jar files into your EAR project because this version of the runtime uses an older version of EMF. If you created your Web service or client with the WAS v6.1.0.3 runtime or earlier copy these files.

  4. Use the

    Lookup namespace data option to change the package names for each namespace. The tool will generate a name based on the content of the schema, but you can change the package name for each namespace found in your schema if you do not like the generated name.

Important: The level of EMF required by the generated SDO code and the level of EMF within WAS conflict. To resolve this issue do the following:

  1. If your EAR project is at the 1.2, 1.3 or 1.4 specification level, open the deployment descriptor for your Web service application, and select the

    Deployment tab.

  2. If your EAR project is at the 1.5 specification level, right-click the EAR and click

    Open WAS Deployment.

  3. Within the

    Applications box, set the

    Classloader mode field to

    parent_last. This causes the class loader to attempt to load classes from its local class path before delegating the class loading to its parent.

For an in depth example of developing a Web service with EMF SDOs, refer to the following article: Developing Web Services with EMF SDOs for complex XML schema