When you need to connect to multiple data centers

These days, when you have a payment systems project that calls for you to route transactions to (or accept transactions from) Fortune 500 industry players like First Data (a.k.a., ‘FDR’ or ‘FDC’) and American Express (a.k.a., ‘AMEX’), you find out quickly that you need to manage multiple connections to geographically disbursed data centers.  [Beyond being just plain good business practices, this dual distributed center approach is pretty much a corporate mandate in a post-Sept. 11th world and is law in some industries.]

So, for example, if you do a project to interconnect to the FDR North processing platform, you’ll need to implement redundant transaction pathways to Melville (New York) and Hagerstown (Maryland).  Likewise, any project you entertain to connect directly to AMEX will result in dual connections to Phoenix (Arizona) and Greensboro (North Carolina).  [AMEX refers internally to these data centers as ‘IPC’ and ‘NROC’ respectively.]  While you don’t need to a pure round-robin (speaking from the Acquirer side here momentarily) implementation, you will be held accountable to implement some transaction distribution between the two channels.  AMEX, in particular, will shut down one of the two channels during certification to force you to demonstrate that all traffic succeeding the shutdown event can be routed through the existing connection.

If you choose to implement a project of this nature using jPOS, you’re in luck because Q2 – jPOS’ ‘second generation’ component assembler – handles this type of requirement out of the box.  I’ll provide an example here, but for a full understanding, your best bet is to purchase the jPOS Programmers’ Guide where a complete step-by-step ‘how to’ can be found.  In general, you’ll see that the jPOS framework is not just a loosely assembled series of commonly used payment systems routines, but is in fact the by-product of a group of individuals forced over time to meet relevant, mission-critical business requirements.  By choosing to implement jPOS, you get to benefit from this team’s hard-earned experience.   

AMEX is a good example to follow here because they provide all of their key documents (ISO8583 Authorization Interface, TCP/IP Guide, Settlement, FTP guide) online.  So, that openness makes it really easy to envision how you connect the dots between theory (i.e., the AMEX specs) and practice (i.e., how things get implemented in jPOS).

In particular, we’re focusing here on implementing the online interface.  We need to the ability to ‘multiplex’ transactions over two connections.  By ‘multiplex’ here, we’re referring to the essential capability of any transaction processing system to handle multiple, in-flight requests and their corresponding responses.  [In an Acquirer-side implementation, a ‘multiplex’ function must also provide a capability to manage ‘unhandled’ messages (i.e., those messages from an authorizing endpoint not related to an outstanding request).]

“QMUX” is Q2’s multiplexer component.  A QMUX component definition for AMEX could look like this:

<mux class="org.jpos.q2.iso.QMUX" logger="Q2" name="amex-mux">
<in>amex-receive</in>
<out>amex-send</out>
<ready>amex.ready</ready>
<unhandled>amex-unhandled</unhandled>
</mux>

QMUX uses a ‘Space’ concept (refer to the jPOS Programmers’ Guide for details on that) in order to communicate with underlying channels.  As Alejandro says in the guide:

This strategy brings into play a whole new set of deployment options, including the ability to multiplex several channels for redundancy/load-balancing. These channels don’t even have to run on the same machine. They can use a distributed/remote space implementation.

So, within a single QMUX definition, there can be multiple channels that can be managed.  The jPOS Programmers’ Guide says:

ChannelAdaptor is…used to configure a (channel); it takes care of keeping it connected to a remote host.  In addition to that, ChannelAdaptor's communication with other components is performed through a Space-based interface, which brings into play the ability to have more than one channel connected to a given host, as well as the ability to distribute channels across multiple Q2 machines in a cluster.

So, continuing our AMEX example, this could be the Q2 component that defines your channel connection to AMEX’s Phoenix location (those are fake host and port values provided here for example only)…

<channel-adaptor name='amex'
    class="org.jpos.q2.iso.ChannelAdaptor" logger="Q2">
<channel class="org.jpos.iso.channel.NACChannel" logger="Q2" realm="amex-channel"
       packager="org.jpos.iso.packager.GenericPackager">
  <property name="packager-config" value="cfg/amex.xml" />
  <property name="host" value="127.0.2.37" />
  <property name="port" value="12720" />
</channel>
<in>amex-send</in>
<out>amex-receive</out>
<reconnect-delay>10000</reconnect-delay>
</channel-adaptor>

…and this could be the Q2 component that defines your channel connection to AMEX’s Greensboro location…

<channel-adaptor name='amex1'
    class="org.jpos.q2.iso.ChannelAdaptor" logger="Q2">
<channel class="org.jpos.iso.channel.NACChannel" logger="Q2" realm="amex-channel"
       packager="org.jpos.iso.packager.GenericPackager">
  <property name="packager-config" value="cfg/amex.xml" />
  <property name="host" value="127.0.2.39" />
  <property name="port" value="12721" />
</channel>
<in>amex-send</in>
<out>amex-receive</out>
<reconnect-delay>10000</reconnect-delay>
</channel-adaptor>

Again, I’m only skimming the service here to give you a feel for jPOS’s ability to meet real-world configurations.  To get a better feel for the entire jPOS framework, I’ll reiterate my suggestion that you purchase a copy of the Programmers’ Guide.