![]() ![]() ![]() ![]() ![]() ![]() |
The Transport SDK provides a layer of abstraction between transport protocols and the AquaLogic Service Bus runtime system. This layer of abstraction makes it possible to develop and plug in new transport providers to AquaLogic Service Bus. The Transport SDK interfaces provide this bridge between transport protocols, such as HTTP, and the AquaLogic Service Bus runtime.
Tip: | Before beginning this chapter, be sure to review Design Considerations first. |
This chapter explains the basic steps involved in developing a custom transport provider. This chapter includes these topics:
The process of designing and building a custom transport provider is complex. This section offers a recommended path to follow as you develop your transport provider. Development of a custom transport provider breaks down into these basic stages:
The section Basic Development Steps outlines the steps you need to take to develop a transport provider, including schema configurations and interface implementations.
The section Important Development Topics discusses in detail several topics that you might need to refer to during the development cycle. This section includes detailed information on topics such as Handling Messages, Transforming Messages, Handling Errors, and others.
For detailed information on packaging and deploying a transport provider, see Deploying a Transport Provider.
Before you begin to develop a custom transport provider, you need to consider and review a number of design issues, which include:
The basic steps to follow when developing a custom transport provider include:
1. Review the Transport Framework Components.
2. Create a Directory Structure for Your Transport Project.
3. Create an XML Schema File for Transport-Specific Artifacts.
4. Define Transport-Specific Artifacts.
5. Define the XMLBean TransportProviderConfiguration.
6. Implement the Transport Provider User Interface.
7. Implement the Runtime Interfaces.
8. Deploy the Transport Provider.
Figure 3-1 illustrates the components that you must implement and configure to create a custom transport provider. The transport manager controls and manages the registration of transport providers and handles communication with AquaLogic Service Bus. A transport provider manages the life cycle and runtime behavior of transport endpoints (resources where messages originate or are targeted). You use the Transport SDK to develop custom transport providers. Using the Transport SDK to develop a custom transport provider is the subject of this chapter.
The parts of the transport subsystem that you must implement and configure include:
Before developing a new transport provider, take time to set up an appropriate directory structure for your project. The recommended approach is to copy the directory structure used for the sample socket transport provider. For a detailed description of this structure, see Sample Location and Directory Structure.
Create an XML schema (xsd
) file for transport-specific definitions. You can base this file on the schema file developed for the sample socket transport provider:
BEA_HOME/weblogic92/samples/servicebus/sample-transport/schemas/
SocketTransport.xsd
where BEA_HOME
is the directory in which you installed AquaLogic Service Bus.
Note: | The SocketTransport.xsd file imports the file TransportCommon.xsd . This file is the base schema definition file for service endpoint configurations. This file is located in BEA_HOME/weblogic92/servicebus/lib/sb-public.jar . You might want to review the contents of this file before continuing. |
Define XML schema for the following transport-specific artifacts in the XML schema file described in the previous section, 3. Create an XML Schema File for Transport-Specific Artifacts.
Note: | Only simple XML types are supported when defining transport provider-specific metadata and headers. For example, complex types with nested elements are not supported. Furthermore, an additional restriction is that there can be at most one header with a given name |
Tip: | Each of these schema definitions is converted into a corresponding Java file and compiled. You will find these converted Java source files for the sample socket transport provider in the directory:sample-transport/build/classes/com/bea/alsb/transports/sock/impl |
EndPointConfiguration is the base type for endpoint configuration, and describes the complete set of parameters necessary for the deployment and operation of an inbound or outbound endpoint. This configuration consists of generic and provider-specific parts. For more information on the EndPointConfiguration schema definition, refer to the documentation elements in the TransportCommon.xsd
file.
You need to specify a provider-specific endpoint configuration in the schema file. Listing 3-1 shows an excerpt from the SocketTransport.xsd
.
<xs:complexType name="SocketEndpointConfiguration">
<xs:annotation>
<xs:documentation>
SocketTransport - specific configuration
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:choice>
<xs:element name="outbound-properties"
type="SocketOutboundPropertiesType"/>
<xs:element name="inbound-properties"
type="SocketInboundPropertiesType"/>
</xs:choice>
<xs:element name="request-response" type="xs:boolean">
<xs:annotation>
<xs:documentation>
Whether the message pattern is synchronous
request-response or one-way.
</xs:documentation>
</xs:annotation>
</xs:element>
...
It is required that each transport provider store metadata (message headers) in a Plain Old Java Object (POJO) and pass that to the pipeline. Examples of information that might be transmitted in the metadata are the Content-Type header, security information, or locale information. A RequestMetaData POJO is a generic object that extends the RequestMetaData abstract class and describes the message metadata of the incoming or outgoing request. The transport provider has to deliver the message metadata to AquaLogic Service Bus runtime in a RequestMetaData POJO. See also Request and Response Metadata Handling.
RequestMetaDataXML is an XML representation of the same RequestMetaData POJO. This XML representation uses Apache XML Bean technology. It is only needed by AquaLogic Service Bus runtime if or when processing of the message involves any actions in the pipeline that need an XML representation of the metadata, such as setting the entire metadata to a specified XML fragment on the outbound request.
You need to specify request metadata configuration in the schema file. Listing 3-2 shows an excerpt from the SocketTransport.xsd
.
<xs:complexType name="SocketRequestMetaDataXML">
<xs:annotation>
<xs:documentation/>
</xs:annotation>
<xs:complexContent>
<xs:extension base="ts:RequestMetaDataXML">
<xs:sequence>
<xs:element name="client-host"
type="xs:string" minOccurs="0">
<xs:annotation>
<xs:documentation>
Client host name
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="client-port" type="xs:int" minOccurs="0">
<xs:annotation>
<xs:documentation>Client port</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
RequestHeadersXML is the base type for a set of inbound or outbound request headers. You need to specify the RequestHeadersXML configuration in the schema file. Listing 3-2 shows an excerpt from the SocketTransport.xsd
.
<xs:complexType name="SocketRequestHeadersXML">
<xs:annotation>
<xs:documentation/>
</xs:annotation>
<xs:complexContent>
<xs:extension base="ts:RequestHeadersXML">
<xs:sequence>
<xs:element name="message-count" type="xs:long" minOccurs="0">
<xs:annotation>
<xs:documentation>
Number of messages passed till now.
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
ResponseMetaDataXML is the base type for metadata for a response to an inbound or outbound message. You need to specify the ResponseMetaDataXML configuration in the schema file. Listing 3-2 shows an excerpt from the SocketTransport.xsd
.
<xs:complexType name="SocketResponseMetaDataXML">
<xs:complexContent>
<xs:extension base="ts:ResponseMetaDataXML">
<xs:sequence>
<xs:element name="service-endpoint-host"
type="xs:string" minOccurs="0">
<xs:annotation>
<xs:documentation>
Host name of the service end point connection.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="service-endpoint-ip"
type="xs:string" minOccurs="0">
<xs:annotation>
<xs:documentation>
IP address of the service end point connection.
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
ResponseHeadersXML is the base type for a set of response headers. You need to specify the ResponseHeadersXML configuration in the schema file. Listing 3-2 shows an excerpt from the SocketTransport.xsd
.
<xs:complexType name="SocketResponseHeadersXML">
<xs:annotation>
<xs:documentation/>
</xs:annotation>
<xs:complexContent>
<xs:extension base="ts:ResponseHeadersXML"/>
</xs:complexContent>
</xs:complexType>
To configure the TransportProviderConfiguration XML bean, edit the transport provider configuration file. This XML file is located in the config directory in the transport provider root directory. See Sample Location and Directory Structure for the location of this file (SocketConfig.xml
) in the sample socket transport provider implementation.
inbound-direction-supported
element to true
. outbound-direction-supported
element to true
. self-described
with the value set to true
. A self-described transport is one whose services are responsible for describing their shape (schema or WSDL) based on their endpoint configuration.UDDI
. See the section Publishing Proxy Services to a UDDI Registry for more info.Tip: | The schema for TransportProviderConfiguration is defined in TransportCommon.xsd , which is located in BEA_HOME/weblogic92/servicebus/lib/sb-public.jar . Refer to the schema file for more information. |
When you add a business or proxy service using the AquaLogic Service Bus Console, you select a transport provider from a menu in the Service Creation wizard. This menu includes the transport providers that are provided with AquaLogic Service Bus and any custom transport providers that were developed with the Transport SDK.
This section discusses the Transport SDK API components that bind your custom transport provider to the AquaLogic Service Bus Console user interface. You must implement these APIs to connect your provider to the user interface.
Tip: | This section assumes that you are familiar with the Service Creation Wizard. See Configuring the Socket Transport Sample for a detailed, illustrated example. |
public boolean isServiceTypeSupported(BindingTypeInfo binding)
This method determines if the transport provider is suitable for the selected Service Type.
public TransportUIError[] validateMainForm(TransportEditField[] fields)
public TransportEditField[] getEditPage(EndPointConfiguration config, BindingTypeInfo binding) throws TransportException
The Transport SDK offers a set of TransportUIObjects that represent fields in the configuration page. For example, you can add text boxes, checkboxes, and other types of UI elements. Use the TransportUIFactory to create them. After creation use the same factory to specify additional properties and obtain TransportEditField objects that can be displayed by the Service Creation wizard.
For a complete list of the available TransportUIObjects, refer to the Javadoc.
Tip: | You can associate events with most of the UI fields. An event acts like a callback mechanism for the TransportUIBinding class and lets you refresh, validate, and update the configuration page. When an event is triggered, the wizard calls the method:updateEditPage(TransportEditField[] fields, String name) throws TransportException |
TransportUIError[] validateProviderSpecificForm(TransportEditField[] fields)
public TransportViewField[] getViewPage(EndPointConfiguration config) throws TransportException
void validateEndPointConfiguration(TransportValidationContext context)
If no error is reported, a new endpoint is created. The Transport Manager then calls the method:
TransportEndPoint createEndPoint(EndPointOperations.Create context) throws TransportException
If this method returns successfully, the new service is listed in the AquaLogic Service Bus Console and the underlying transport configuration is associated with an endpoint on the TransportProvider.
Note: | The endpoint configuration is saved in the AquaLogic Service Bus session and does not need to be persisted or recovered in case of a server restart by the transport provider. |
Tip: | For the sample socket transport provider, you can find the implementations of these interfaces in the sample-transport/src directory. |
A new custom transport provider must implement the following runtime interfaces. For a summary of the Transport SDK interfaces and related classes, see Transport SDK Interfaces and Classes. For detailed information on interfaces and classes, see the AquaLogic Service Bus Javadoc description.
Tip: | For the sample socket transport provider, you can find the implementations of these interfaces in the sample-transport/src directory. |
Note: | Only implement the TransportWLSArtifactDeployer interface if the transport provider needs to deploy WebLogic Server-related artifacts, such as EAR/WAR/JAR files, that go into a WebLogic Server change list at the time of endpoint creation. For more information, see When to Implement TransportWLSArtifactDeployer. |
Note: | Only implement the Transformer interface if the transport provider needs to work with non-standard payload bindings, for example, anything other than Stream, DOM, SAX, or XMLBean. For more information, see Transforming Messages. |
For detailed information on deployment, see Deploying a Transport Provider.
This section discusses several topics that you will encounter while developing a custom transport provider. These topics include:
This section discusses message handling in transport providers and includes these topics:
The Transport SDK features a flexible representation of message payloads. All Transport SDK APIs dealing with payload use the Source interface to represent message content.
The Source-derived message types provided with the Transport SDK include:
Note: | StreamSource is a single use source; that is, it implements the marker interface SingleUseSource. With the other Sources, you can get the input stream from the source multiple times. Each time the Source object gets the input stream from the beginning. With a SingleUseSource, you can only get the input stream once. Once the input is consumed, it is gone (for example, a stream from a network socket); however, AquaLogic Service Bus buffers the input from a SingleUseSource, essentially keeping a copy of all of its data. |
Note: | If you implement a Source class for your transport provider, you need to determine whether you can re-get the input stream from the beginning. If the nature of the input stream is that it can only be consumed once, it is recommended that your Source class implement the marker interface SingleUseStream. |
The Transport SDK provides a set of Transformers to convert between Source objects. You can implement new transformations, as needed, as long as they support transformations to/from a set of canonical representations. See Transforming Messages for more information. See also Designing for Message Content.
When implementing inbound endpoints to deliver the inbound message to AquaLogic Service Bus runtime, you need to call TransportManager.receiveMessage()
. The transport provider is free to expose the incoming message payload in either one of the standard Source-derived objects, such as stream, DOM or SAX, or a custom one.
If AquaLogic Service Bus needs to send a response message back to the client that sent the request, it will call methods setResponseMetaData()
and setResponsePayload()
followed by close()
on InboundTransportMessageContext to indicate that the response is ready to be sent back. When AquaLogic Service Bus runtime calls the inbound transport message context close()
method, this will be done from a different thread than that on which the inbound request message was received. The transport provider should be aware of this as it may affect the semantics of transactions. Also, the transport provider cannot attempt to access the response payload and/or metadata until close()
method has been called.
It is required that each transport provider store metadata and headers in a Plain Old Java Object (POJO) and pass that to the pipeline. There are some cases where AquaLogic Service Bus requires an XMLBean. In these cases, you need to implement a conversion from POJO to XMLBean using the API.
The following are the methods you must provide to convert from a POJO to XML:
For the reverse direction (XML to POJO) you need to implement:
Each transport provider is responsible for specifying the character set encoding of the incoming message payload to AquaLogic Service Bus. For outgoing messages (outbound request and inbound response), the transport provider is responsible for telling AquaLogic Service Bus what character set encoding to use for the outgoing payload. The character-set encoding is specified in request and response metadata.
In virtually every case, the character-set encoding that the transport is responsible for inserting into the metadata is exactly the encoding that is statically specified in the service configuration. One of the few exceptions to this is HTTP transport, which inspects Content-Type for any “charset” parameters and overrides any encoding configured in the service. This is necessary in order to conform to HTTP specifications. Other transport protocols may need to handle similar issues.
Tip: | In general, the encoding for a service is fixed. If someone sends an UTF-16 encoded message to a proxy that is specified to be SHIFT_JIS, then that is generally considered to be an error. Transport providers should not need to inspect the message simply to determine encoding. |
For outgoing messages, the transport provider tells AquaLogic Service Bus what encoding it requires for the outbound request, and AquaLogic Service Bus performs the conversion if necessary.
Transports should always rely on this encoding for outgoing messages and should not assume that it is the same as the encoding specified in the service configuration. If there is a discrepancy, the transport can choose to allow it, but others could consider it an error and throw an exception. Also the transport has the additional option of leaving the encoding element blank. That leaves the pipeline free to specify the encoding (for example, via pass-through).
If a given transport provider supports proxy service endpoints, it is possible to configure the request pipeline such that there is a routing step that routes to that provider’s proxy service. Furthermore there could be a Publish or a Service Callout action that sends a message to a proxy service instead of a business service. This use case is referred to as co-located calls.
The transport provider needs to be aware of co-located calls, and handle them accordingly. Depending on the nature of the proxy service endpoint implementation, the transport provider may choose to optimize the invocation such that this call bypasses the entire transport communication stack and any inbound authentication/authorization, and instead is a direct call that effectively calls TransportManager.receiveMessage()
immediately.
Tip: | AquaLogic Service Bus has implemented this optimization with the HTTP, File, Email and FTP transport providers. The JMS provider does not use this optimization due to the desire to separate the transactional semantics of send operation versus receive operations. |
If you want to use this optimization in a custom transport provider, you need to extend the CoLocatedTransportMessageContext class and call its send()
method when TransportProvider.sendMessageAsync()
is invoked.
When AquaLogic Service Bus runtime sends a message to an outbound endpoint and there is a response message to be returned, the transport provider must return this response asynchronously. That means TransportSendListener.onReceiveResponse()
or TransportSendListener.onError()
methods need to be called from a different thread than the one on which TransportProvider.sendMessageAsync()
was called.
If the transport provider has a built-in mechanism by which the response arrives asynchronously, such as responses to JMS requests or HTTP requests when the async response option is used, it happens naturally. However, if the transport provider has no built-in mechanism for retrieving responses asynchronously, it can execute the outbound request in a blocking fashion and then schedule a new worker thread using the TransportManagerHelper.schedule()
method, in which the response is posted to the TransportSendListener.
When AquaLogic Service Bus needs to set either the request payload to an outbound message or the response payload to an inbound message, it asks the transport provider to do so through an object derived from the Source interface. The transport provider then needs to decide what representation the underlying transport layer requires and use the Transformer.transform()
method to translate the Source object into the desired source.
Tip: | For more information on message transformation, see Designing for Message Content. For a list of built-in transformations, see Built-In Transformations and Source and Transformer Classes and Interfaces. |
A custom transport provider can support new kinds of transformations. Suppose a transport provider needs to work with a DOM object in order to send the outbound message. When called with setRequestPayload(Source src)
, the transport provider needs to call the method: TransportManagerHelper.getTransportManager().getTransformer().
.
transform(src, DOMSource.class, transformOptions)
The return value of the method gives a DOMSource, which can then be used to retrieve the DOM node.
Note: | If the transport provider requires a stream, there is a shortcut: each Source object supports transformation to stream natively. |
You can add new transformations to a custom transport provider. For example, suppose you want to add a new kind of Source-derived class, called XYZSource. For performance reasons, transport providers are encouraged to provide conversions from XYZSource to one of the two canonical Source objects, XmlObjectSource and StreamSource when applicable. Without such transformation, generic transformers will be used, which rely on the StreamSource representation of XYZSource. Of course, if XYZSource is a simple byte-based Source with no internal structure, then relying on the generic transformers is usually sufficient. Note that any custom transformer that is registered with TransportManager is assumed to be thread-safe and stateless.
To support attachments, the transport provider has three options:
multipart/related
. Both HTTP(S) and Email transports rely on this third option for supporting attachments.A TransportOptions object is used to supply options for sending or receiving a message. A TransportOptions object is passed from the transport provider to the transport manager on inbound messages. On outbound messages, a TransportOptions object is passed from the AquaLogic Service Bus runtime to the transport manager, and finally to the transport provider.
This section includes these topics:
The transport provider supplies these parameters to TransportManager.receiveMessage()
:
TransportManager.receiveMessage()
when an error occurs during the AquaLogic Service Bus pipeline processing. The options for throwing the exception include: throw the exception back to the inbound message or create a response message from the error and notify the inbound message with the response message. Typically, you set Throw On Error to true when QOS is exactly-once (for transactional messages). For example, JMS/XA sets this flag to true to throw the exception in the same request thread, so it can mark the exception for rollback. HTTP sets the flag to false, because there is no retry mechanism. The error is converted to a status code and a response message is returned.
For outbound processing, the AquaLogic Service Bus runtime supplies these parameters to the transport manager, which uses some of the parameters internally and propagates some parameters to TransportProvider.sendMessageAsync()
. These parameters include:
The request mode is defined as an enumeration with two values: REQUEST_ONLY
(also called “one-way”) and REQUEST_RESPONSE
. These modes are interpreted as follows for requests and responses:
REQUEST_ONLY
.There are three different use cases to consider with respect to the effect runtime exceptions have on the transactional model. These cases include:
These cases are discussed in this section.
The exception occurs somewhere in the request pipeline but before the outbound call to the business service, as shown in Figure 3-2. For example, executing a specific XQuery against the contents of the request message raises an exception.
If there is a user-configured error handler configured for the request pipeline, the error will be handled according to the user configuration. Otherwise, the proxy service will either catch an exception when calling TransportManager.receiveMessage()
or will be notified in the InboundTransportMessageContext.close()
method of the error through response metadata, based on the transport options passed as an argument to the receiveMessage()
call. If the proxy service indicates that the exception should be thrown, surround receiveMessage()
with a try/catch clause and mark the transaction for rollback.
The exception occurs during the business service call, as shown in Figure 3-3. The outbound transport provider either:
TransportProvider.sendMessageAsync()
. For example, the outbound provider throws an exception if there was an error while establishing a socket connection to external service. This situation could occur if the business service cannot be called because of an incorrect URL, a faulty connection, or other reasons. In these cases, the transport provider must raise an exception. TransportSendListener.onError()
. For example, if the business service was called, but the call resulted in an error (such as a SOAP fault), the transport provider needs to call TransportSendListener.onError()
instead of raising an exception.
In the first instance, the exception handling is the same as that described in Case 1. In the second instance, if there is an error handler configured for the response pipeline, the error is handled according to the user configuration. Otherwise, the exception is propagated back to the proxy service endpoint in InboundTransportMessageContext.close()
through the response metadata.
The exception occurs sometime after the business service call in the response pipeline, as shown in Figure 3-4. Again, in the absence of a user-defined error handler for the response pipeline, the proxy service endpoint is notified of the error with the InboundTransportMessageContext.close()
method with appropriate response metadata. If the inbound transport endpoint is a synchronous transactional endpoint, it is guaranteed that the transaction that was active at the time request was received is still active and it may be rolled back. If the inbound endpoint is not transactional or not synchronous, there is not an inbound transactional context to roll back, so some other action might need to be performed.
Universal Description, Discovery, and Integration (UDDI) is a standard mechanism for describing and locating Web services across the internet. You might want to publish proxy services based on a custom transport provider to a UDDI registry. This allows proxy services to be imported into another AquaLogic Service Bus server in a different domain as the one hosting the business service.
To publish a proxy service, the transport provider needs to define a tModel that represents the transport type in the “UDDI” section of TransportProviderConfiguration XML schema definition. (For more information on the schema-generated interfaces, see Schema-Generated Interfaces.)
This tModel must contain a CategoryBag with a keyedReference whose tModelKey is set to the UDDI Types Category System and keyValue is “transport.” You are required to provide only the UDDI V3 tModel key for this tModel.
If UDDI already defines a tModel for this transport type, it is recommended that the definition be copied and pasted into the UDDI section.
An example of such a tModel is provided in Listing 3-6.
<?xml version="1.0" encoding="UTF-8"?>
<ProviderConfiguration xmlns="http://www.bea.com/wli/sb/transports">
…
…
<UDDI>
<TModelDefinition>
<tModel tModelKey="uddi:bea.uddi.org:transport:socket">
<name>uddi-org:socket</name>
<description>Socket transport based webservice</description>
<overviewDoc>
<overviewURL useType="text">
http://www.bea.com/wli/sb/UDDIMapping#socket
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference keyName="uddi-org:types:transport"
keyValue="transport"
tModelKey="uddi:uddi.org:categorization:types"/>
</categoryBag>
</tModel>
</TModelDefinition>
</UDDI>
</ProviderConfiguration>
If UDDI does not already define a tModel for this transport type, AquaLogic Service Bus can publish the tModel you define here to configured registries. When a UDDI registry is configured to AquaLogic Service Bus, the “Load tModels into Registry” option can be specified. That option causes all of the tModels of AquaLogic Service Bus, including the tModels for custom transport providers, to be published to the UDDI registry. After deploying your transport provider, you can update your UDDI registry configuration to publish your tModel.
During UDDI export, TransportProvider.getBusinessServicePropertiesForProxy(Ref) is called and the resulting map is published to the UDDI registry. The provider is responsible for making sure to preserve all important properties of the business service in the map so that during the UDDI import process the business service definition can be correctly constructed without loss of information.
During UDDI import, TransportProvider.getProviderSpecificConfiguration(Map) is called and the result is an XmlObject that conforms to the provider-specific endpoint configuration schema, which goes into the service definition.
Tip: | OASIS, the Organization for the Advancement of Structured Information Standards, is responsible for creating the UDDI standard. To read more about UDDI, including the full technical specification, go to: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=uddi-spec |
Two sets of transport provider interfaces are provided that deal with individual service registration. TransportProvider has methods like create/update/delete/suspend/resume and TransportWLSArtifactDeployer has the same methods. This section discusses these two implementations and explains when you need to implement TransportWLSArtifactDeployer.
Only implement TransportWLSArtifactDeployer if your provider needs to make changes to WebLogic Server artifacts in the AquaLogic Service Bus domain. The methods on TransportWLSArtifactDeployer are only called on an Administration Server. In this case, changes are made through the DomainMBean argument that is passed in, and then the changes are propagated to the entire cluster.
The TransportProvider methods are called on all servers (Administration and Managed Servers) in the domain. Because you cannot make changes to AquaLogic Service Bus domain artifacts on a managed server, the purpose of the method calls on TransportProvider is to update its internal data structures only.
When a given Transport provider implements the TransportWLSArtifactDeployer interface, the methods on TransportWLSArtifactDeployer are called before the corresponding methods on TransportProvider. For example, TransportWLSArtifactDeployer.onCreate()
is called before TransportProvider.createEndPoint()
.
For more information on TransportWLSArtifactDeployer, see Summary of General Interfaces.
![]() ![]() ![]() |