3

In our internal architecture, we have several Tomcat servers which distribute the workload and isolate the different processes of our business. We are planning to move into an approach where several tasks (mostly BD related) will be handled by a Tomcat endpoint (load balanced for availability and performance), but we are troubled in determining what could be the best practice oriented method for internal communication between the different web apps that run in the different Tomcat servers. We've already been using HornetQ, MQTT (Mosquitto based) and HTTP for different aspects, but considering this planned endpoint should expose internally an API to the others servers.

The main goal of this architecture change is to avoid problems related to the fact of having different pieces of software doing similar work, but with different rules and algorithms, thus leading to coding mistakes and non-uniform behaviors across the system for a single entity.

What should be considered? What inter-process-communication would be actually recommended? Some kind of ESB perhaps?

Gonzalo Vasquez
  • 141
  • 5

1 Answers1

1

The main goal of this architecture change is to avoid problems related to the fact of having different pieces of software doing similar work, but with different rules and algorithms, thus leading to coding mistakes and non-uniform behaviors across the system for a single entity.

The way you do that is to create an API, and require everyone to use that API for their business processes. By establishing a simple architecture, you can provide a common platform that everyone can follow.

How you implement that platform is entirely up to you. As you've already pointed out, there are several ways to accomplish this. I would consider an Actor model implementation like Akka; it's got IPC built-in (in the form of messaging mailboxes), robust features for redundancy and reliability, and is infinitely scalable. You can build a workflow system on top of it, if you wish.

Eliminating the technical debt is going to be a gradual process of moving each bit of existing functionality to the new API, and removing its multiple occurrences elsewhere.

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
  • Years ago I tested akka for some batch processes, but ended using zmq for better performance (although not same functionality), any comments on Apache Camel perhaps? About the "technical debt", I'm aware that it won't be fast and will take a while, but the goal is to make the overall system better. – Gonzalo Vasquez Feb 08 '17 at 17:32
  • The Actor Model isn't about performance; it's about *scalability.* If you're looking for raw, clock-cycle performance characteristics, there are better solutions. – Robert Harvey Feb 08 '17 at 18:09
  • I'd definetely give a try to Akka in this scenario, as the situation I refered to was years ago, and in a different company. By making the system "better" I mean better arquitecture and overall inner order. – Gonzalo Vasquez Feb 08 '17 at 18:41