Using Middleware in System Integration

Asked

Viewed 127 times

3

In the company where I work, we need to integrate our desktop system, which has a local database with a system that will be running on a cloud server. Our scenario is 2000 clients performing an asynchronous integration.

The rear application will expose the integration services using Rest.

Our customers will have an application that performs scheduled tasks consuming the integration services.

The question is whether to use a Middleware or not:

Option 1: The Customer application directly consumes the services from the rear.

Option 2: Use a Middleware application, where the client system consumes a single service that adds the messages in an integration queue. The Middleware is responsible to consume the queue and integrate with the services of the rear application.

  • 2

    The two approaches are viable and depend a lot on other aspects that are not in your question and that possibly would not even have to be because they are too expensive to obtain and available only with the system already in advanced state of development, as well as detailed reports about cargo tests. Both solutions seem to be very good and will probably be equivalent in most realistic cases, only being able to demonstrate real differences in very specific scenarios.

  • 1

    Hello, welcome to [en.so]! Look, not wanting to get out of the subject too much, not being boring, or anything, and still running the risk of being wrong, but if this question refers to the same system of this other one here and if this is some critical system, on which companies or people really depend, I strongly advise those responsible to consult directly with an architect to help in the decisions. It seems a complex case, full of uncertainty and with little information available. The risk of failure is gigantic.

  • 1st part: @utluiz, thank you very much for the answer, regarding the architecture it is already defined: 1st Integrator: We will have an application running in the stores that monitor an integration queue table, this table is maintained by the store application. The integrator transforms the data into Json, and consumes a Rest service provided by middleware that adds the messages in a queue. Integrator controls the & #Xa; priority of sending information between registrations and movement.

  • Part 2: 2nd Middleware: Consumes the Input Queue by sending messages to your recipients. This application will still have an interface layer so that the support team (1st level) , can see integration problems. 3º Services: The services will be responsible for receiving the information through the JSON format and persisting in the database. These services will be divided into microservices 4th Database: It will be a single database with tenant control.

  • 3rd part: 5º Let’s have some service-consuming interfaces: Control panel, Reports... (performace, load test) available only with the system already in advanced state of development. Then the doubts arise and we post here to try some answer that helps add to the project.

1 answer

-2

Using a message-oriented middleware is a great alternative, as it ensures greater decoupling and scalability due to its asynchronous nature.

  • Use a middleware and message-oriented Broker buddy, remember if your solution starts to complicate and you see in it the need for orchestration use an ESB

Browser other questions tagged

You are not signed in. Login or sign up in order to post.