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?

Improve this question
4
  • What is the problem with "Pros and Cons"? Commented Feb 7, 2017 at 20:39
  • 2
    You haven't stated any goals or requirements (other than the desire to make whatever you do "best practice-oriented," whatever that means), so your question is unanswerable. Commented Feb 7, 2017 at 21:00
  • 1
    @gnat I've just wiped that part away Commented Feb 8, 2017 at 12:24
  • @RobertHarvey added the main objective of this idea Commented Feb 8, 2017 at 12:24

1 Answer 1

Reset to default
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.

Improve this answer
3
  • 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. Commented Feb 8, 2017 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. Commented Feb 8, 2017 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. Commented Feb 8, 2017 at 18:41

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.