Here is a simple Use Case implemented in IBM IntegrationBus 10 vs TIBCO BusinessWorks™ 6

Which one is easier to implement?

What is best practice and what not?

Which one has the most flexibility when it comes to configuration?

We have a simple (common) scenario when we need to expose a Soap Web service (SOAP with XML) or any other service (MQ, Database, etc) as a REST Web Service (HTTP with JSON).

IBM Integration Bus 10:

IIB has on out of the box adaptor (HTTPInput node) that can be used to expose an http service supporting different type of messages (XML,JSON, etc).
EX:

IIB supports HTTP (1.0 or 1.1) format or HTTP over SSL (HTTPS) format.

The HTTPInput node handles messages in the following message domains:

MRM, XMLNSC, XMLNS, MIME, BLOB, XML (this domain is deprecated; use XMLNSC), JSON, DFDL.

Security can be implemented for the HTTP flows by using either Basic-Auth or Integrated Windows Authentication (NTLM, SPNEGO or Kerberos).

The methods supported by HTTPInput are HTTP POST and HTTP GET.

HTTP message cannot be persistent, have no associated order and are non-transactional, but if the message flow interacts with external resource (Ex database or MQ, etc), then these interactions are performed in a transaction.

The HTTP node have implemented commit or rollback if necessary. If the flow ends with an error, then the message can be rolled back by this node and a fault message is generated and returned to the client.  

The HTTPInput node provides commit or rollback, depending on how the message flow ended, and how it is configured for error handling (how failure terminals are connected, for example).

If you have used HTTPInput node in a flow, then you must have an HTTPReply node in the same flow or send the message to another flow that have an HTTPReply node.

A flow that uses HTTPInput node can use the default approach with broker-wide listener that is started when a message flow with HTTP Node is started or you can use an embedded listener specific to a integration server (all flows deployed on that integration server will use the same listener).

The flow can be used in multi-threading scenario, max number of threads per flow can be set.  

One issue with this is that when the max number of instances is achieved, the memory allocated cannot be reclaimed by OS even if the current number of threads are decreasing later.

If a client sends a gzip or deflate compressed request to the HTTPInput node, it can be extracted using the Decompress input message option.

‍TIBCO BusinessWorks™ 6:

BusinessWorks haa HTTP Receiver node that is a processstarter activity and starts the process based on the receipt of an HTTPrequest.

This node is used to expose flows as HTTP (REST/JSON).

Tibco BW support HTTP 1.1 and HTTP 2 version. The default is HTTP 1.1.

HTTP Receiver can use Basic Authentication, SSL certificate and JWT Authentication. Older security protocols TLS v1.0, v1.1 and SSL v3 are not supported, to prevent security vulnerabilities.

HTTP Receiver supports GET and POST methods.

Most of those properties are configurated throw HTTPConnector:

Flow using HTTPReceiver node cannot have persistent messages and has no associated order. The message cannot be transactional.

HTTP Receiver can use compression using the HTTP/1.1 GZIP compression. By default, this is disabled.

HTTP Receiver can use Compressible Mime Types: istext/html, text/xml, text/plain.

A very interesting feature that you can activate is the "Write to File" function that writes incoming requests that exceed the specified threshold size to a file instead of storing the request in memory.

You can accept large incoming requests without consuming a great deal of memory.

This function has some configuration options, as Threshold Data Size(bytes) representing the maximum size (in bytes) of an incoming request that can be kept in the memory.

Another very good feature is that you can set Multi-Threaded with property "ProcessStarter".

This will use by default:

Minimum Queued Thread Pool Threads= 10

Maximum Queued Thread Pool Threads= 75, but those can be configured at HTTP Connector node level.

As a conclusion, the described scenario can be implemented with ease using both products.

The advantage of Tibco BusinessWorks is that is has a bit more configuration options then IBM Integration Bus (eg number of threads that is rather fixed in IIB regarding the memory consumption, HTTP settings that in Tibco BW can be configured at flow level throw HTTP Connector, etc).

The increase configuration possibilities offered by Tibco BusinessWorks add increase complexity, so we can say that is a bit easier to implement this scenario in IBM Integration Bus if we do not need to much configuration regarding HTTP Connector.

There are more differences between IBM Integration Bus and Tibco BusinessWorks regarding the product as a whole, one of them is how much memory an instance of the server/node consume and how easy is to move it to cloud or to a containerized environment.

In this regard Tibco BusinessWorks 6 has an advantage, being more lightweight then IBM Integration Bus 10.

IBM try to catch up with the new version of Integration Bus (IBM App Connect Enterprise) that suffered a lot of changes to decrease the memory consumption and to offer real solution to use it in containerized environment.

‍