Our Messaging Framework Architecture

During the initial development of our ERP software, we had searched messaging solutions for our messaging requirements. We evaluated JMS providers’ packages. Shortly at the end, there was no solution fitting our case. At that time, some of the developers were criticizing JMS with the argument that messaging vendors shaped the specification in order to be complaint with their current products. Adding a new dependency (3rd party JMS provider) would increase overall cost of our solution by price and by administration. We decided to write a new messaging framework that highly integrates with our applications. We aimed to make message-based programming easy and embedded to our platform. Development cost of such a framework would not be feasible for many projects but we had time and resource at that time. On the other hand, every enterprise application would need a message-oriented middleware (MOM) for enterprise application integration (EAI) if multi-site (multi-server) deployment occurs.

I summarize the benefits that we wanted to provide with this decision (We didn’t implement JMS but our API is simpler than JMS API, JMS implementation maybe in the future):

1. High-integration to Applications: Message-driven beans (MDB) enable EJBs to utilize JMS messaging. When we evaluated, JMS providers’ solutions were hard to bind into development and deployment environment. We aimed high-integration with our applications and database objects similar to EJB-MDB model.

2. No Administration Overhead: One of the most important problems of JMS providers was administration mechanism. We couldn’t find an embedded messaging product. They were requiring installation and management. When we try to install our application on Unix-based servers, there was no support by these providers (Oops, where is my MOM?). Database support is another hindrance.

3. Both Synchronous and Asynchronous Communication: RMI was strong in synchronous communication and JMS was strong in asynchronous communication, we had tried to combine these both models. In this way, we managed to send a message to send synchronously or asynchronously.

4. Easy User-User Groups (Roles) Usage as a Message Consumer: When we inspected JMS API, the only way to make a user a message consumer is to create a new queue naming same with user name. However that mustn’t be such that hard (We had to create a new queue in JMS providers’ admin console). User groups are another type of message consumer that requires similar procedure to be a message consumer. We wanted that every system-generated message would flow in this messaging middleware reaching users, user groups or program without manual definition.

5. Workflow Integration: We benefit from our messaging framework as workflow infrastructure backbone. Users can register workflow actions and make system produce messages to them.

6. Replication: One of the most important usages of framework is in replication mechanism. We didn’t use database replication support since product-dependent. Instead, we developed a replication mechanism based on MOM and integrated with applications. Application database events are listened and if replication is defined for this operation. Then by using MOM’s synchronous transacted one-to-many message, replication is done.

7. Electronic Data Interchange (EDI): Application’s transactional data transfer among systems is a very tricky problem. In business world, there is a huge amount of document exchange among companies-departments (B2B). If systems can talk each other, paper transfer and data re-entry can be minimized and some errors may be prevented. Systems can talk each other with EDI mechanism. MOM can transfer electronic documents to other party and get response. Users should use EDI mechanism within application GUI easily by selecting for instance a purchase order and pushing send button as a sales order for receiving side. Sending and receiving sides may use same system or different system (Different semantics and dictionaries are a very big challenge here). In some circumstances, MOM should transfer this EDI document by converting different formats like XML or legacy EDI formats.

There were many transportation options but we used HTTP protocol for transportation. We had to handle timeout problems. We used XML as core message format. Needless to say, messages are stored in database tables for guaranteed delivery. Messaging middleware uses the same JVM with applications.

To make it work across systems seamlessly and reliably is hard and a must in enterprise systems. Leaks in message transactions are much harder to fix than a local application transaction leak since a problem may lock all systems at the same time. Think a geographically distributed system, the system would be very delicate to fix the problems (high shutdown-restart cost).

Our Messaging Framework Architecture: