One of the most asked questions in a project from the client was how feasible is it to use Database as the intermediary transport layer for Websphere Message Broker. No doubt there is a long term benefit in using WMQ but the question is more short sighted as per the immediate benefits of leveraging the existing RDBMS framework.To make a case for implementing a solution based on Websphere Message broker, this question needs to be answered as to why WMQ and not RDBMS.So listed below is a few pointers that I think will help answer this question to some extent.
| Sl# | WebSphere MQ | Database Tables | Description |
| 1 | One time transfer per UOW | Have to handle multiple connections per UOW | Unit of Work(UOW): To generate one EDI message or a transaction the implementation effort involved varies between the two approach. |
| 2 | Out of the box implementation | Custom implementation within ESB | ESB has native MQ connectivity where-as Database calls require development effort on the scale of 20-40hrs per transaction.DB approach will need access logic custom coded for each transaction within ESB. |
| 3 | Data is not replayable | Data is replayable | MQ messages are consumed once-and-only once vs. db data can be replayed without additional development effort. |
| 4 | No dependency on network | Dependency on network | ESB access to database has dependency on network availability. |
| 5 | New implementation for Sterling Integrator(SI) | Existing framework for SI | MQ connectivity option has to be explored by SI team vs Configurable services for Database connectivity needs to be established within ESB. |
| 6 | Can use same data to route to multiple targets | Has to be defined per target | MQ ESB can publish information to multiple systems without impacting the existing consumer. |
| 7 | Measurable Performance overhead | Performance overhead per transaction will vary per transaction | Database connectivity consumes resources within ESB which is comparitively higher than native MQ connectivity. |
| 8 | No rollback of data required | Roll back has to be maintained within ESB | Concept of Rollback does not apply for MQ connectivity.Custom code to monitor and maintain transactionality has to be defined within ESB for Database based connection. |
| 9 | Decouples ESB and enterprise application. In case of System maintenance of either applications the messages will not fail, but will get queued up and be consumed once the application is back up. | Tight coupling between ESB and database. In case database goes down for system maintenance, message will fail in ESB and will have to reprocessed or retry logic needs to be included | This will reduce Production Support and troubleshooting effort, and also allows Applications to do maintenance independent of ESB layer. |
| 10 | Speeds up development effort. Once the message contract is finalized each of the developments teams (ESB and enterprise application) can work in parallel without having to rely on either of the teams to complete development and testing. | ESB team will still have to rely on tables being created, and access given to DB tables (or rely on application team) to verify messages are being created correctly, and also to trigger messages | Once the message contract is finalized each of the developments teams can work in parallel without having to rely on either of the teams to complete development. |
What’s next?
If you’re still using WebSphere Message Broker, it might be time to think about upgrading your ESB. Whether you’re using an unsupported version of WMB or want the features of the newest IIB release, use our best practices compiled over the course of countless migrations to ease the process and maximize your IBM investment.
