Usage patterns for deploying custom data binders

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. WAS provides an extension to the Java 2 Enterprise Edition (J2EE) 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.

We can learn about the CustomBinder API in the topic CustomBinder interface. The topic Custom data binders includes general information about custom binders and the topic Custom binding providers reviews how they 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 J2EE 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 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 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 WAS internal components.

• Deploy the custom binders for one or more application

  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. 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

  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. 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 you 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 Java virtual machine settings.

• Deploying 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 Manage shared libraries.

• 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.

To review the documentation used for APIs and SPIs, see Reference: Generated API documentation. Follow the instructions in this topic that lead you to the API and SPI interfaces.

You can also review the specifications for the standards and APIs used in developing Web services.

---

Related concepts
Custom data binders Custom binding providers Related tasks
Manage shared libraries Related reference
CustomBinder interface Java virtual machine settings Web services: Resources for learning

 

---