APM Connectors and Configuration
This section covers:
The detailed differences between different type of APM connectors (connectors that are used for providing transport level communications with Service Providers)
Their use in a context of the Synchronous and Asynchronous EFT frameworks
Their extensibility and configuration aspects
Consider the following typical APM configuration:
Syntax
<Connection name=”myAPM”
class=”com.triversity.core.eft.EFTService”
creditServiceHandlerClassName=”myAPMHandler”
eftProviderName=”Service Provider Name”
sequential=”true”>
<APMConnection connectionClass=”mySocketConnectionClass”
delegateWriteToConnection=”true”>
<Destination id=”127.0.0.1:1200” connectionTimeout=”25”/>
</APMConnection>
</Connection>
In the above sample configuration, the connectionClass
determines
the class to be used for providing communications. This class normally extends
the core classes that provide support for Socket, Dial, URL and JMS communications,
or alternatively it can implement the IAPMConnection
interface
directly. This class takes responsibility of handling service provider specific
communication requirements. For example, a Service Provider may require certain
message headers to be included in the request and response message body. Normally
an instance of IAPMConnection
interface continuously
listens to the service provider for any response and returns when one is received
in full from the Service Provider.
If the APM connection configuration has the delegateWriteToConnection
flag
set, then all requests are forwarded to the writePersistent
method
of the MySocketConnection
class. Otherwise DataOutputStream
is
obtained from the MySocketConnection
and the
request object’s write method is called with the DataOutputStream
passed
as a parameter. The first method of sending the request is more flexible,
since it allows more control for implementer of the IAPMConnection
interface.
If the EFTService
has the Sequential flag
set, then the service class calls the writePersistent
method
of the APMConnection
class. In our example,
this method will in turn call the writePersistent
method
of the MySocketConnection
class. This flag
in a sense is redundant considering delegateWriteToConnection
flag,
and if used, should be synchronized with it.