Integration B2B can be used for connecting with chain partners using the ebXML adapter. The ebXML is actually a set of standards enclosing ebMS which is the messaging service standard that is supported by Integration B2B. Basically it is a SOAP based standard over Internet. So the coupling with the chainpartners is based on HTTP. That's why the B2B server needs a HTTP server to receive the messages. But in this case (and the other internet-based B2B-protocols) it is also particularly handy for our high-availability architecture, because a simple loadbalancer can dispatch the requests over the two (or more) B2B Servers. The B2B servers both share the same Infrastructure database. So you have to do the configuration only once.
Since they're stateless there is not much more to do than simply install two Application Servers with Integration B2B that both use the same database. There's is actually no use for clustering or webcache. Clustering might be convenient for maintenance using Grid-control, but not really for run-time. Since we do not use the file-adapter, we can have this in an active-active setup.
Using the file adapter you have to be aware that files may only be processed by one of the two instances. There is a tip.properties-property that set the two in an active-passive configuration. But I learned that there are troubles with that. Also B2B has particular requirements about the naming of the files that might not be supported by your tradingpartners. So you might need a script or BPEL PM installation in front of B2B that takes care of these issues.
Since our configuration has to communicate with chainpartners over a WAN or internet we don't want to have the HTTP Servers directly connected to the WAN/internet. Of course there is a Firewall in front of it. But it is a good practice to define a Demilitarized Zone (DMZ) using two firewalls, to make it even harder to break in. The Oracle documentation suggests to put the HTTP Server of the Integration B2B application server into the DMZ, or to have another one that connects directly to the B2B server (by passing its own HTTP Server). This coupling is then based on AJP (Apache Java Protocol, if I'm right). The problem with that is that it is a little hard to monitor and maintain since you need to have several ports open in the internal firewall. We therefor choose to have the Integration B2B server use its own HTTP-server on it's own port. We installed a Oracle HTTP Server 2.0 (OHS) from the Oracle Application Server's companion CD (10.1.3). We particularly choose the 2.0 because it contains additional features needed by SSO that we might need in the future when pulishing portals to the Chainpartners.
The HTTP Server 2.0 is configured as a regular Apache 2.0 server so that it acts as both a forward and reverse proxy server.
An example of the proxy-configuration is below:
#LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
#LoadModule proxy_ftp_module modules/mod_proxy_ftp.so
LoadModule proxy_http_module modules/mod_proxy_http.so
Allow from all
CustomLog logs/access_proxyfwd8085.log common
ProxyPass / http://nllvm12c:1234/
ProxyPassReverse / http://nllvm12c:1234/
CustomLog logs/access_proxyrev4080.log common
You can simply put this piece in a proxy.conf file that you include in the httpd.conf of the OHS.
All the incoming traffic comes in on port 4080. This is the default port that Axway Cyclone (another B2B gateway product) uses. It is convenient to standardize that so that all the chainpartners use the same port, particularly when you use a Hop in the middle. The Hop then only has to configure it's firewall to open up port 4080. Internally we use other ports. So the incoming traffic on port 4080 are rerouted in this example to the B2B server (nllvm12c) on port 1234.
In the tip.properties files of the Integration B2B server you need to put in the ip address of the loadbalancer of the proxyserver (in the picture the right one). The proxyserver above is listening on port 8085 for these requests, so that is the port you need to fill in in the tip.properties as the proxy port.
It is very important to use different ports for the internal traffic and the external (incoming requests): the internal firewall should have other ports open than the external firewall to have the DMZ secure. I think many security-officers prefer to have internally also other protocols, like the AJP protocol in the architecture suggested by Oracle. But for the convenience of configuration and maintainability we choose the configuration above.