Introduction

In general, Web services exchange data in the form of XML messages that conform to a specific XML schema. To work directly with an XML schema, Java programmers, who are accustomed to Java objects, have to work with the low-level XML APIs. In many cases, it is very inconvenient for Java programmers to use XML APIs, such as Document Object Model (DOM), to develop their Web services applications, and much easier for them to manipulate the Java objects and then have the run time system handle the low-level serialization and deserialization of the Java objects.

To work this way, you have to define certain rules to map the XML schema types to Java types and vice versa. The process of mapping from the XML schema type to the Java type is sometimes called the data binding. Currently, a few open standards are available to define the XML to Java data binding, among which are Java API for XML-based RPC (JAX-RPC) and Java Architecture for XML Binding (JAXB) (see Resources). However, not all XML schema types are currently supported by these open specifications because of the XML schema's complexity.

The JAX-RPC specification addresses this limitation by providing a workaround that maps all the unsupported schema types to a generic data structure: javax.xml.soap.SOAPElement, or SOAPElement for short. Similar to the DOM element, the SOAPElement is a data structure that programmers can use to navigate the XML content using the SOAP Attachment API for Java (SAAJ) (see Resources). For those unsupported schema types (see Appendix), JAX-RPC requires programmers to deal with the XML data directly, instead of just using familiar Java types.

Although mapping to the SOAPElement is acceptable for certain data-centric applications, it is usually not recommended for those strongly typed systems. Furthermore, for data-centric applications, the SOAPElement might not always be the best choice. For example, you might want to use another generic type system such as Service Data Object (SDO) (see Resources). Even for already supported XML schema types, you might want to look for alternative data mapping options instead of using the default JAX-RPC mapping. This decision is especially important when you have to face some legacy types to which you want to map the XML schema types.

A need therefore exists to extend or overwrite the existing mappings for certain schema types. This article describes a pluggable mechanism to develop and deploy the custom data binders for WebSphere Application Server V6.

An SDO schema example

Listing 1 shows an XML schema that is defined by the Service Data Object (SDO) specification.

<xsd:schema
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:sdo="commonj.sdo"
  targetNamespace="commonj.sdo">

  <xsd:element name="datagraph" type="sdo:DataGraphType"/>
  
  <xsd:complexType name="DataGraphType">
  <xsd:complexContent>
    <xsd:extension base="sdo:BaseDataGraphType">
      <xsd:sequence>
        <xsd:any minOccurs="0" maxOccurs="1" 
                 namespace="##other" processContents="lax"/>
      </xsd:sequence>
    </xsd:extension>
  </xsd:complexContent>
  </xsd:complexType>

  <xsd:complexType name="BaseDataGraphType" abstract="true">
  <xsd:sequence>
    <xsd:element name="models" type="sdo:ModelsType" minOccurs="0"/>
    <xsd:element name="xsd" type="sdo:XSDType" minOccurs="0"/>
    <xsd:element name="changeSummary"
                 type="sdo:ChangeSummaryType" minOccurs="0"/>
   </xsd:sequence>
  <xsd:anyAttribute namespace="##other" processContents="lax"/>
  </xsd:complexType>
    
  <xsd:complexType name="ModelsType">
  <xsd:sequence>
    <xsd:any minOccurs="0" maxOccurs="unbounded" 
             namespace="##other" processContents="lax"/>
  </xsd:sequence>
  </xsd:complexType>

  <xsd:complexType name="XSDType">
  <xsd:sequence>
    <xsd:any minOccurs="0" maxOccurs="unbounded" 
        namespace="http://www.w3.org/2001/XMLSchema" processContents="lax"/>
  </xsd:sequence>
  </xsd:complexType>

  <xsd:complexType name="ChangeSummaryType">
  <xsd:sequence>
    <xsd:any minOccurs="0" maxOccurs="unbounded" 
             namespace="##any" processContents="lax"/>
  </xsd:sequence>
  <xsd:attribute name="create" type="xsd:string"/>
  <xsd:attribute name="delete" type="xsd:string"/>
  </xsd:complexType>

</xsd:schema> 

As SDO becomes increasingly popular among the Java developer community, a need to develop a Web services application using SDO APIs becomes apparent. However, when you develop a Web services application using the above schema, it is likely that you are not going to see the SDO types present at the mapped Service Endpoint Interface (SEI) because the schema type with QName {commonj.sdo}DataGraphType and its referencing types contain the xsd:anyAttribute, which is not currently supported by JAX-RPC.

It is apparently not convenient for SDO programmers if these SDO types are mapped to the SOAPElement. SDO already provides various APIs to manipulate the data, and it is awkward for SDO programmers to juggle between the SDO and SOAPElement APIs. We use this schema in this article as an example for illustrating how to build a custom binder for the DataGraphType and how to deploy it with applications.

Back to top

Develop the custom binder

The custom binder is a function that works with the pairing of a particular XML schema type and Java type. The custom binder defines serialize and deserialize methods to convert between Java objects and SOAPElements. After the custom binder is plugged into the run time system, this binder interacts with the runtime through the use of SOAPElement in the following way.

Unlike conventional deserializers, the custom binders do not rely on the low-level parsing events such as Simple API for XML (SAX) events from the run time system to build the Java object. Instead, the run time system first renders the incoming SOAP message into an appropriate SOAPElement and then passes it to the custom binder for further rendering. For example, if the incoming message contains an SDO datagraph, the run time system:

1. Recognizes the <sdo:Datagraph> snippet.
2. Queries its type mapping system to locate an appropriate custom binder (for example, SDOCustomBinder) for the datagraph data.
3. Builds an appropriate SOAPElement which represents the incoming SDO datagraph.
4. Passes the SOAPElement to the SDOCustomBinder.

Within its deserialize method, the SDOCustomBinder extracts the content from the passed SOAPElement and then builds a concrete DataGraph object with a commonj.sdo.DataGraph type. The entire flow is illustrated in Figure 1.

Similarly, when a Java object is serialized, the run time system locates the appropriate binder, which then converts the Java object to a SOAPElement. The runtime then serializes the SOAPElement to the raw message on the wire. In this case, the SOAPElement acts as an intermediate form of a SOAP message so that custom binders do not need to pay attention to the details of writing out the raw XML data into the output stream.

CustomBinder interface

WebSphere Application Server V6 defines a CustomBinder interface, which programmers implement to provide the concrete custom binding for a specific XML schema type. As shown in the Listing 2, besides deserialize and serialize methods, the CustomBinder interface has three properties that are accessible through corresponding getter methods. These three properties are the QName for the XML schema type, the QName scope, and the Java type, to which the schema type maps.

package com.ibm.wsspi.webservices.binding;

public interface CustomBinder {
    public final static String QNAME_SCOPE_ELEMENT = "element";
    public final static String QNAME_SCOPE_COMPLEXTYPE = "complexType";
    public final static String QNAME_SCOPE_SIMPLETYPE = "simpleType";
    
    public javax.xml.namespace.QName getQName();
    public String getQNameScope();
    public String getJavaName();
    public javax.xml.soap.SOAPElement serialize(
           Object bean,
           javax.xml.soap.SOAPElement rootNode,
           CustomBindingContext context) 
    throws javax.xml.soap.SOAPException;

    public Object deserialize(
           javax.xml.soap.SOAPElement source,
           CustomBindingContext context) 
    throws javax.xml.soap.SOAPException;
}

Method getQName
The getQName method returns the QName of the target XML schema type. Custom binders only work with the root level schema type definition; that is, the global definition of <xsd:complexType>, <xsd:simpleType>, and <xsd:element> that does not use the type attribute. Sometimes the first two are called the named type while the latter is called the anonymous type since it does not have any real name for the type definition that is embedded within the <xsd:element> definition. The custom binder does not work with the <xsd:element> with the type attribute.

For named types, the getQName method returns the QName of the schema type definition; for anonymous types, the getQName method returns the QName of the enclosing element. In cases where a named type and an anonymous type use the same QName, they are differentiated by the qnameScope property.

Method getQNameScope
The getQNameScope method returns the binder qnameScope property to indicate whether the schema type is a named type or an anonymous type. Accordingly, the value for the qnameScope is either element (for an anonymous type), complexType (for an xsd:complexType), or simpleType (for an xsd:simpleType).

The qnameScope property affects how the custom binder interacts with the run time system because of differences between the named types and the anonymous types. For an anonymous type, the binder has to be aware of its enclosing element; therefore, SOAPElement, that is returned from serialize method, has the same QName as that of the enclosing element. For a named type, the binder does not have the knowledge of the referencing element. It is the responsibility of the runtime to pass the custom binder a valid QName of referencing element.

Method getJavaName
The getJavaName method returns the fully qualified class name for the Java type with which this custom binder works. The class can be either an interface or a concrete class. The object returned from the deserialize method has a type that is compatible with the name that is returned from the getJavaName method.

Method serialize
The serialize method returns a SOAPElement which the custom binder builds from a Java object. The Java object is passed from the run time system and its type is expected to match what is returned from the getJavaName method. The SOAPElement parameter does not have child elements except that it has a valid QName. This parameter serves as a reference for the binder to create the final SOAPElement.

In most cases, the binder implementation appends the child elements to the passed root SOAPElement. The run time system guarantees the correctness of the SOAPElement QName. Therefore, the custom binder for named types keeps the QName of the root element because the binder does not have knowledge of the enclosing element. For anonymous types, the binder implementation should make sure that the returned SOAPElement always has the QName matching the defined schema type. The CustomBindingContext parameter does not have any concrete methods defined for the WebSphere Application Server V6 release. This parameter is currently a placeholder for future releases.

Method deserialize
The deserialize method returns a Java object that the custom binder builds from the passed root SOAPElement. The type of the returned Java object must match what is returned from the getJavaName method. Unlike the parameter of serialize method, the passed SOAPElement contains the original XML data with all the necessary namespace declarations.

Example: SDO DataGraph binder

Listing 3 illustrates an implementation of the SDO DataGraph binder where convertToSDO and convertToSAAJ are utility methods that convert between a SOAPElement and an SDO object.

package test.sdo.binder;

import javax.xml.namespace.QName;
import javax.xml.soap.SOAPElement;

import com.ibm.wsspi.webservices.binding.CustomBinder;
import com.ibm.wsspi.webservices.binding.CustomBindingContext;


public class DataGraphBinder implements CustomBinder {

    public QName getQName() {
        return new QName("commonj.sdo", "DataGraphType");
    }

    public String getQNameScope() {
        return CustomBinder.QNAME_SCOPE_COMPLEXTYPE;
    }

    public String getJavaName() {
        return commonj.sdo.DataGraph.class.getName();
    }
	    
    public javax.xml.soap.SOAPElement serialize(
           Object bean,
           SOAPElement rootNode,
           CustomBindingContext context) 
           throws javax.xml.soap.SOAPException { 
        // convertToSAAJ is a utility method to convert  
        // the SDO DataGraph to the SOAPElement
        return convertToSAAJ(bean, rootNode);
    
    public Object deserialize(
           SOAPElement source,
           CustomBindingContext context) 
           throws javax.xml.soap.SOAPException {
        // convertToSDO is a utility method to convert
        // the SOAPElement to the SDO DataGraph
        return convertToSDO(source);
    }
}

Back to top

Define the custom binding provider

The custom binder defines the run time behavior for serialization and deserialization. The remaining question is how to plug the custom binders into both emitter tools and the run time system so that the emitter tools can generate appropriate artifacts, and the run time system can augment its existing type mapping system to reflect the applied custom binders and invoke them as appropriate.

A custom binder usually works with a specific XML schema type, while real-life applications often involve a few related XML schema types. Therefore, you need a mechanism to aggregate and declare various custom binders to provide a complete custom binding solution. The concept of the custom binding provider is introduced here to define a declarative model that can be used to plug in a set of custom binders to either emitter tools or a run time system.

This section explains how to create a custom binding provider and its metadata file and how the binding provider can be used for development.

Custom binding provider

The custom binding provider is the packaging of custom binder classes with a declarative metadata file. Its main purpose is to aggregate related custom binders to support particular user scenarios. One typical case is that a binding provider is created for a specific application that has a few XML schema types that are not supported by the JAX-RPC specification. Normally, a one-to-one relation is found between a binding provider and an XML schema file which contains a few schema types for the custom binders to manage. However, this relationship is not restricted and it is legitimate to create a binding provider to support a number of XML schema files.

The declarative metadata file, CustomBindingProvider.xml, is an XML file that is normally packaged along with the custom binder classes in a single Java Archive (JAR) file, and located in the /META-INF/services/ directory. After a provider JAR file is packaged, it includes all necessary information (both binaries and metadata file) and is ready to be used by both the tools and the run time system.

Custom binding provider schema
Listing 4 is the XML schema for the CustomBindingProvider.xml file. The top-level type is the providerType that contains a list of mapping elements. Each mapping element defines the associated custom binder and some properties such as xmlQName, javaName, and qnameScope, which correspond to those properties that are defined by associated custom binder. The providerType also has an attribute called scope which has a value of either server, application, or module. The scope attribute is normally used by server deployment to resolve the conflict and to realize a custom binding hierarchy.

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema 
    targetNamespace=
       "http://www.ibm.com/webservices/customdatabinding/2004/06" 
    xmlns:customdatabinding=
        "http://www.ibm.com/webservices/customdatabinding/2004/06"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    elementFormDefault="qualified" attributeFormDefault="qualified">
	
   <xsd:element name="provider" type="customdatabinding:providerType"/>
   
   <xsd:complexType name="providerType">
   <xsd:sequence>
     <xsd:element name="description" type="xsd:string" minOccurs="0"/>
     <xsd:element name="mapping" minOccurs="0" maxOccurs="unbounded">
      <xsd:complexType>
        <xsd:sequence>
          <xsd:element name="description" type="xsd:string" minOccurs="0"/>
          <xsd:element name="xmlQName" type="xsd:QName"/>
          <xsd:element name="javaName" type="xsd:string"/>
          <xsd:element name="qnameScope" 
                       type="customdatabinding:qnameScopeType"/>
          <xsd:element name="binder" type="xsd:string"/>
        </xsd:sequence>
       /xsd:complexType>
      </xsd:element>
       <xsd:attribute name="scope" 
             type="customdatabinding:ProviderScopeType" default="module"/>
       </xsd:sequence>
   </xsd:complexType

  <xsd:simpleType name="qnameScopeType">
      <xsd:restriction base="xsd:string">
         <xsd:enumeration value="simpleType"/>
         <xsd:enumeration value="complexType"/>
         <xsd:enumeration value="element"/>
      </xsd:restriction>
  </xsd:simpleType>

  <xsd:simpleType name="ProviderScopeType">
     <xsd:restriction base="xsd:string">
         <xsd:enumeration value="server"/>
         <xsd:enumeration value="application"/>
         <xsd:enumeration value="module"/>
     </xsd:restriction>
  </xsd:simpleType>  
</xsd:schema>

CustomBindingProvider.xml for the SDO DataGraph example
Listing 5 is an example of the CustomBindingProvider.xml file for the previously mentioned SDO DataGraph schema. In this example, it defines a mapping between a schema type DataGraphType and a Java type commonj.sdo.DataGraph. The binder to realize this mapping is called test.sdo.SDODataGraphBinder.

<cdb:provider
	xmlns:cdb="http://www.ibm.com/webservices/customdatabinding/2004/06"
   xmlns:sdo="commonj.sdo">
   <cdb:mapping>
   		<cdb:xmlQName>sdo:DataGraphType</cdb:xmlQName>
   		<cdb:javaName>commonj.sdo.DataGraph</cdb:javaName>
   		<cdb:qnameScope>complexType</cdb:qnameScope>
   		<cdb:binder>test.sdo.SDODataGraphBinder</cdb:binder>
   </cdb:mapping>   
</cdb:provider>

Apply the binding provider to generate development artifacts

The custom data binding affects how the development artifacts are generated from the Web Services Description Language (WSDL) file. The WSDL2Java emitter tool (see Resources) that ships with WebSphere Application Server V6 can use the binding provider JAR file to generate appropriate development artifacts, such as Service Endpoint Interface (SEI), the JSR109 mapping metadata, and so on.

<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="http://sdo.test" 
   xmlns:impl="http://sdo.test" 
   xmlns:intf="http://sdo.test" 
   xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" 
   xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" 
   xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   xmlns:sdo="commonj.sdo">

 <wsdl:types>
  <schema elementFormDefault="qualified" targetNamespace="http://sdo.test" 
       xmlns="http://www.w3.org/2001/XMLSchema" xmlns:sdo="commonj.sdo">
   <import namespace="commonj.sdo" schemaLocation="sdo.xsd"/>
  </schema>
 </wsdl:types>

 <wsdl:message name="echoResponse">
  <wsdl:part element="sdo:datagraph" name="return"/>
 </wsdl:message>

 <wsdl:message name="echoRequest">
   <wsdl:part element="sdo:datagraph" name="parameter"/>
 </wsdl:message>

 <wsdl:portType name="EchoService">
   <wsdl:operation name="echo">
     <wsdl:input message="impl:echoRequest" name="echoRequest"/>
     <wsdl:output message="impl:echoResponse" name="echoResponse"/>
    </wsdl:operation>
 </wsdl:portType>

 <wsdl:binding name="EchoServiceSoapBinding" type="impl:EchoService">
   <wsdlsoap:binding style="document" 
                     transport="http://schemas.xmlsoap.org/soap/http"/>
     <wsdl:operation name="echo">
        <wsdlsoap:operation soapAction=""/>
        <wsdl:input name="echoRequest">
         <wsdlsoap:body use="literal"/>
        </wsdl:input>

       <wsdl:output name="echoResponse">
          <wsdlsoap:body use="literal"/>
       </wsdl:output>
    </wsdl:operation>
  </wsdl:binding>

  <wsdl:service name="EchoServiceService">
     <wsdl:port binding="impl:EchoServiceSoapBinding" name="EchoService">
       <wsdlsoap:address location="http://<uri>"/>
    </wsdl:port>
  </wsdl:service>

</wsdl:definitions>

Without the custom data binding, running the WSDL2Java command below generates SEI as shown in Listing 7, where its parameter type, as dictated by JAX-RPC, is javax.xml.soap.SOAPElement.

public interface EchoService extends java.rmi.Remote {
    public javax.xml.soap.SOAPElement 
           echo(javax.xml.soap.SOAPElement parameter)                        
             throws java.rmi.RemoteException;
}

Suppose the provider JAR file for the SDO DataGraph schema is sdobinder.jar. You can apply the custom data binding by using the -classpath option on the WSDL2Java tool. WSDL2Java searches its classpath to locate all the files with the same file path of /META-INF/services/CustomBindingProvider.xml. Run this WSDL2Java command to generate SEI as shown in Listing 8, where the parameter type is commonj.sdo.Datagraph, as expected.

WSDL2Java -role develop-server -container web -classpath sdobinder.jar echo.wsdl

public interface EchoService extends java.rmi.Remote {
    public commonj.sdo.DataGraph 
           echo(commonj.sdo.DataGraph parameter) 
             throws java.rmi.RemoteException;                            
}

Naturally, the provider JAR file has to be made available at run time to make a successful client invocation, regardless of whether it is a stub-based client or a Dynamic Invocation Interface (DII) client. Similarly for the service, the provider JAR file has to be available at service run time.

Back to top

Deploy the custom binders

After the custom binders are implemented and packaged, they are ready for deployment with various applications. This section first discusses various roles that are involved in the custom data binding and then lists a few common usage patterns regarding how to deploy the custom binders.

Roles involved in custom data binding

Four roles are involved with custom data binding and each role has its own set of responsibilities. These role definitions follow, to some degree, what is defined by the J2EE™ specification (see Resources).

• Custom binding provider -- The binding provider is responsible for implementing the required custom binders, declaring these binders in a CustomBindingProvider.xml file, and then packaging various binder classes into a JAR file for availability.
• Application developer -- The application developer is responsible for applying the custom binding provider JAR file and generating the appropriate development artifacts.
• Application assembler -- The application assembler is responsible for understanding the application requirements in terms of the custom data binding and then deciding whether and how to package the provider JAR file as part of the application.
• Application deployer -- If the provider JAR file is not packaged with the application, the application deployer is responsible for configuring the shared libraries to make the custom binding support available to the applications. If the application is not already deployed, the deployer is also responsible for running the Web services deployment tools when the application is installed.

Common usage patterns

The custom data binders can be deployed in various ways to provide additional flexibility beyond the standard JAX-RPC mapping. Three primary usage patterns exist for deploying the custom data binders:

1. The first usage pattern is to deploy the custom binders at the server level so that all the applications that run at this server are affected by the deployed custom data binders. This pattern is useful in the case where some fundamental XML types are introduced but are not supported by the standard JAX-RPC mapping. This situation occurs frequently for new Web services specifications, which tend to define some new schema types. For example, WS-Addressing specification (see Resources) defines an EndpointReferenceType schema type which is not supported by JAX-RPC mapping rules. Because this pattern often requires augmenting the server classpath, the use of it has a significant impact on the server runtime and affects all the installed applications. This pattern is most suitable for WebSphere Application Server internal components only.
2. The second usage pattern is to deploy the custom binders for one or more applications so that only those applicable applications are affected by the deployed custom binders. This pattern is useful in the case where relevant XML schema types apply to a set of applications. By applying this pattern, you can share the custom binding within one set of applications and yet achieve the isolation between different sets of applications.
3. The third usage pattern is to deploy the custom binders for a specific Web module within an application so that only that Web module is affected by the deployed custom binders. This pattern is useful in the case where the finest granularity for custom binding is required. This pattern does not apply for the EJB module because of the classloader nature for the EJB module; that is, the EJB module and its referenced library actually belong to the entire application (see Resources).

Deployment tasks

This section gives more details about how to deploy the custom binders that correspond to the three usage patterns that are defined above.

For the first usage pattern, set the scope attribute of the declared binding provider as server. This setting guarantees the higher priority for declared binders in the case of conflicts between the server and applications. Put the provider JAR file in an appropriate place so that it can be picked up by the server runtime. Configure the server path and make the provider JAR files be part of the server classpath. See Resources for information on how to configure the server class path.

For the second usage pattern, set the scope attribute of the declared binding provider as application. This setting guarantees higher priority for declared binders in case of conflicts between the application and the module. If the custom binders are used by more than one application, configure a shared library for those applications to reference. See Resources to learn how to configure shared libraries. If the custom binders are used by one application only, the deployer can choose to pre-package the provider JAR file with the application so that the configuration can be avoided.

For the third usage pattern, set the scope attribute of the declared binding provider as module. The only way to apply the custom data binding for this pattern is to pre-package the provider JAR files with the Web module; for example, put the JAR files into the /WEB-INF/lib directory.

Back to top

Conclusion

This article introduced background and conceptual information on data binding, explained why custom data binding is necessary for handling certain XML schema types, and provided a detailed description of how to deploy custom binders in various usage scenarios. Descriptions of how to develop and package the custom binders follows in the appendix.

Back to top

Appendix: Schema types not supported by JAX-RPC 1.1

The schema types not supported by JAX-RPC version 1.1 include, but are not limited to:

• Complex data type with mixed=true
• Complex data type containing xsd:choice, xsd:group, xsd:attributeGroup, xsd:anyAttribute
• Complex data type inheritance by restriction (except restriction over arrayType, for example,
  
  
  

  <complexType name="DerviedType"> <complexContent> <restriction base="BaseType> ... </restriction> </complexContent> </complexType>

  
  
  
  
• Complex data type with sequence having maxOccurs > 1, for example,
  
  
  

  <complexType name="Foo"> <sequence maxOccurs="2"> ... </sequence> </complexType>

  
  
  
  
• Complex data type with all having maxOccurs > 1, for example,
  
  
  

  <complexType name="Foo"> <all maxOccurs="2"> ... </all> </complexType>

  
  
  
  
• Nested content models in a single complex type, for example,
  
  
  

  <complexType name="NestedType"> <sequence> <element name="elem1" type="string"/> <element name="elem2"> <complexType> <sequence> <element name="elem3" type="string"/> </sequence> </complexType> </element> </sequence> </complexType>

  
  
  
  
• Identity constraints (key, keyref, unique)
• Union simple data types

Resources

1. Read JAX-RPC specification
2. Read JAXB specification
3. Read SAAJ specification
4. Read SDO specification
5. Read WSDL2Java command reference
6. Read J2EE specification
7. Obtain the WS-Addressing schema
8. Understand the WebSphere classloader
9. Learn how to configure the classpath for the WebSphere Application Server
10. Learn how to configure the shared libraries path for the WebSphere Application Server

Other resources

• Get involved in the developerWorks community by participating in developerWorks blogs.
  
  
• Browse for books on these and other technical topics.
  
  

About the author

Ping Wang is one of the developers of the IBM WebSphere Web services engine. Previously, he was a developer for WebSphere Application Server System Management and focused on how to manage distributed processes using Java Management Extension (JMX). You can contact Ping at pacific@us.ibm.com.

Rate this article

Comments

Back to top

Table of contents

• Introduction
• Develop the custom binder
• Define the custom binding provider
• Deploy the custom binders
• Conclusion
• Appendix: Schema types not supported by JAX-RPC 1.1
• Resources
• About the author
• Comments

Next steps from IBM

• Try: WebSphere Application Server
• Briefing: Building SOA solutions and managing the service lifecycle
• Buy: WebSphere Application Server

Dig deeper into WebSphere on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers