Usage patterns for deploying custom data binders for JAX-RPC applications
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 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.
Roles involved in custom data binding
Four roles are involved with custom data binding. These roles that are defined by the Web Services for Java EE specification are as follows:
- Custom binding provider is responsible for implementing the required custom data binders, declaring these binders in a CustomBindingProvider.xml file and packaging the binding classes into a Java archive (JAR) file.
- Application developer is responsible for applying the custom binding provider JAR file and generating the development artifacts.
- Application assembler needs to understand the application requirements in terms of the custom data binding and decides how to package the custom provider JAR file as a part of the application.
- Application deployer configures the shared libraries to make custom data binding support available to the applications. This needs to be done if the custom provider JAR file is not packaged with the application. If the application is not deployed, the deployer has to run the web services deployment tools after the application is installed.
Common usage patterns
The custom binder provider package can be deployed in various ways to provide flexibility beyond the standard JAX-RPC mapping standards. Three primary deployment usage patterns are as follows:
- Deploy the custom data binders at the server level
This pattern ensures that all the applications 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 WAS internal components.
- Deploy the custom binders for one or more application
Use this pattern if we only want specified applications to be affected by the custom data binders and if relevant XML schema types apply to a set of applications. We can share the custom data binders within a set of applications while achieving isolation between different sets of applications.
- Deploy the custom binders for a specific web module within an application
Use 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. We cannot use this pattern with EJB modules because the module and its referenced library belong to the entire application.
Usage patterns
This section reviews deploying custom data binders using one of the three patterns:
- Server level deployment
If we deploy the custom data binders at the server level, we 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.
- Deploy custom data binders for one or more applications
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.
- Deploy the custom data binders for a specific web module within an application
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.
Related:
Custom data binders for JAX-RPC applications Custom binding providers for JAX-RPC applications Manage shared libraries CustomBinder interface for JAX-RPC applications Java virtual machine settings Additional Application Programming Interfaces (APIs) Web services specifications and APIs