|
|
This chapter explains how to package and deploy a custom transport provider and includes these topics:
You must package your custom transport provider as a self-contained EAR file. You can then deploy the EAR with the AquaLogic Service Bus Kernel EAR and other AquaLogic Service Bus related applications.
| Tip: | The sample socket transport provider example illustrates how a transport provider is organized and deployed. See Sample Socket Transport Provider for more information. |
Each transport provider consists of two distinct parts:
| Tip: | A best practice is to package the transport provider so that the configuration and runtime parts are placed in separate deployment units. This practice makes cluster deployment simpler. See Deploying to a Cluster for more information. See also Transport Provider Components. |
This section discusses how to deploy a transport provider.
| Tip: | For more information on deploying applications to AquaLogic Service Bus, see the AquaLogic Service Bus Deployment Guide. |
After you create a deployable EAR file for your transport provider, you need to deploy it to the AquaLogic Service Bus domain. You can deploy the EAR by whatever method you prefer:
config.xml file <app-deployment>
<name>My Transport Provider</name>
<target>AdminServer, myCluster</target>
<module-type>ear</module-type>
<source-path>$USER_INSTALL_DIR$/servicebus/lib/mytransport.ear</source-path>
<deployment-order>1234</deployment-order>
</app-deployment>
| Note: | The deployment order of your transport provider EAR file should be high enough so that the entire ALSB Kernel EAR is deployed before the transport provider. |
On server restart, you want to ensure that your deployed transport can immediately begin to handle service requests. To ensure immediate transport availability, extend the weblogic.application.ApplicationLifecycleListener class and use the preStart() method to register your transport using TransportManager.registerProvider().
The sample socket transport has an ApplicationListener class that you can use for reference, located at ALSB_HOME/samples/servicebus/socket-transport/src/com/bea/alsb/transports/sock.
| Note: | The sample socket transport’s ApplicationListener class uses the postStart() method instead of the preStart() method. You should use the preStart() method. |
When extending ApplicationLifecycleListener, be sure to register your extending class in META-INF/weblogic-application.xml. The sample socket transport provides the following entry for its ApplicationListener class in ALSB_HOME/samples/servicebus/sample-transport/META-INF/weblogic-application.xml:
<weblogic-application>
<listener>
<!-- This class gives callbacks for the deployment lifecycle and socket
transport is registered with ALSB whenever the application is started.
-->
<listener-class>com.bea.alsb.transports.sock.ApplicationListener
</listener-class>
</listener>
</weblogic-application>
Once a transport provider has been registered with ALSB, the undeployment or unregistration of the transport provider is not supported.
In a cluster environment, only the configuration part of the transport provider needs to be deployed on the AquaLogic Service Bus domain Administration Server. The runtime parts need only be deployed on the managed servers for load-balancing and failover.
If you deploy the runtime and configuration parts of the transport provider in a single deployment unit, the resulting EAR file needs to be aware of where it is being deployed (Administration Server or Managed Server) and exhibit only configuration behavior on the Administration 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 (!isAdminServer || !clusterExists)
_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 or administration node in a single server domain.
Furthermore, as mentioned previously, in a cluster environment, TransportProvider.createEndPoint() and deleteEndPoint() are called on an Administration 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.
|