Each custom transport provider requires two files: an EAR file and a JAR file. A third file, a transport plug-in, is required in order to use the custom transport provider in JDeveloper.

You must package your custom transport provider as a self-contained JAR file, which defines the transport, and an EAR file, which can be deployed on the WebLogic Server. The EAR file can include the JAR file, or you can make the JAR file a library on which the EAR file depends. Using the latter method means you only need to maintain one copy of the JAR file.

To make the transport available to Service Bus, install the EAR file and, optionally, the JAR file, in /MW_HOME/osb/lib/transports. Typically, both the EAR file and the JAR file are placed in this directory for Service Bus transports, but it is not required that the JAR file be placed there. The plug-in file you create, which makes the custom transport provider available to offline tools, points to the JAR file.

To make the transport available to the Oracle Service Bus Console and runtime, deploy the EAR file to the server with the Service Bus Kernel EAR file and other Service Bus related applications. The sample socket transport provider example illustrates how a transport provider is organized and deployed. For more information, see Creating a Sample Socket Transport Provider.

This section describes the structure of the JAR and EAR files for your custom transport providers.

To see an example of any of the files listed in this section, build the sample socket transport provider, as described in Building and Deploying the Sample . You can then view all the packaged artifacts. You can also review the sample build.xml file to see an example of how to compile and deploy the custom transport provider.

Once you create your transport provider EAR file, JAR file, and optional plug-in for JDeveloper, you need to add the files to the JDeveloper installation so they can be picked up by JDeveloper.

After you create a deployable EAR file for your transport provider, you need to deploy it to the Service Bus domain.

<app-deployment>
    <name>My Transport Provider</name>
    <target>AdminServer, myCluster</target>
    <module-type>ear</module-type>
    <source-path>$MW_HOME$/osb/lib/transports/mytransport.ear</source-path>
    <deployment-order>6</deployment-order>
</app-deployment>

Once a transport provider has been registered with Service Bus, the undeployment or unregistration of the transport provider is not supported.

Your transport provider must be deployed on all the servers and clusters where Service Bus is deployed.

This means that if Service Bus is deployed only on the Admin Server (which it always is), you must deploy the transport provider on the Admin Server. If Service Bus is deployed in an admin + Managed Server topology, you must deploy the transport provider on the Admin Server and that particular Managed Server. If Service Bus is deployed in a cluster, you must deploy your transport provider on the Admin Server and the cluster. Note that Service Bus is always deployed on the Admin Server regardless of the domain topology.

The application code inside your transport provider EAR file needs to be aware dynamically of where the transport is being deployed (such as the Admin Server or a Managed Server) and exhibit only configuration behavior on the Admin Server and only runtime behavior on the Managed Server.

For example, in the initialization pseudo code in some_transport.ear, you can use this logic to decide whether or not to activate the configuration or runtime portion of the provider:

protected SomeTransportProvider() throws TransportException {
    . . . some other initialization code . . .
    if (!isRuntimeEnabled)
        _engine = new RuntimeEngine(. . .);
}

In this case, creating an instance of the RuntimeEngine class is runtime behavior and only needs to happen on a managed node in a multi-server domain or on the administration node in a single server domain.

Furthermore, in a cluster environment, TransportProvider.createEndPoint() and deleteEndPoint() are called on an Admin Server as well as Managed Servers in the cluster (with the exception of WLS HTTP router/front-end host). Some transport providers can choose not to do anything other than registering the fact that there is an endpoint with the given configuration, such as HTTP. In general the transport provider needs to examine whether createEndPoint() or deleteEndPoint() is called on the administration or Managed Server to decide the appropriate behavior.