Custom data binders are used to map XML schema types with Java objects. Custom data binders provide bindings for XML schema types that are not supported by the current Java API for XML-based Remote Call Procedure (JAX-RPC) specification. WebSphere® Application Server provides an extension to the Web Services for Java Platform, Enterprise Edition (Java EE) programming model called the CustomBinder interface that implements these custom bindings for a specific XML schema type. The custom binding provider is the package for the custom data binders that is imported into the runtime.
To learn more about the CustomBinder API, see the CustomBinder interface for JAX-RPC applications information. For general information about custom binders, see the custom data binders for JAX-RPC applications information. See the custom binding providers for JAX-RPC applications information to review how custom binding providers are packaged for development.
This usage pattern reviews how to deploy the provider package to your runtime, as well as the roles involved in the custom binding process.
This pattern ensures that all the applications that are running on the server are affected by the custom data binders and is useful if fundamental XML types are introduced but are not supported by the standard JAX-RPC mapping rules.
This type of situation occurs frequently for new Web services specifications that define new schema types. For example, the WS-Addressing specification defines an EndpointReferenceType schema type that is not supported by the JAX-RPC mapping rules. Because this pattern requires augmenting the server classpath, it has a significant impact on the server runtime and affects the installed applications. This pattern is most suitable for WebSphere Application Server internal components.
Use this pattern if you only want specified applications to be affected by the custom data binders and if relevant XML schema types apply to a set of applications. You can share the custom data binders within a set of applications while achieving isolation between different sets of applications.
Using this pattern ensures that a specific Web module is affected by the deployed custom data binders. This pattern is useful when fine granularity for custom binding is required. You cannot use this pattern with EJB modules because the module and its referenced library belong to the entire application.
If you deploy the custom data binders at the server level, you need to set the scope attribute of the declared binding provider as server. Setting the value to server guarantees a higher priority for declared binders if there are conflicts between the server and applications. The custom binding provider JAR file needs to be in the appropriate place to be picked up by the server runtime. Configure the server path and make the custom binding provider JAR file a part of the server classpath. To learn about values used in configuring the server classpath, see the Java virtual machine settings information.
To deploy custom data binders for one or more applications, set the scope attribute of the declared custom binding provider as application. Setting the value to application guarantees higher priority binders in case of conflicts between the application and the module. If the custom data binders are used by more than one application, configure a shared library for the applications to reference. To learn about values used in configuring the shared libraries path, see the managing shared libraries information.
To deploy custom data binders for a specific Web module within an application, set the scope attribute of the declared custom binding provider to the value module. The only way to apply the custom data binder for this pattern is to pre-package the custom binding provider JAR file with the Web module, for example, place the JAR file in the /WEB-INF/lib directory.