I read an article about how applications interact . And what remains to me completely incomprehensible is how the topologies of the integration solution "gateway" and "bus" differ:

enter image description here

I would be grateful if someone explains the difference between them.

  • @PavelMayorov is in the original article, the gateway and broker call one - vitidev
  • @PavelMayorov, gateway == centralized broker (option 3 in the picture) - Ksenia
  • Well, if I do not confuse, then I give an analogy. Broker is like mail - he knows who is addressed to (or rather, who needs to deliver) and what needs to be delivered and the postman will take it to the right place. In the case of a bus, the postman will pass through all the apartments with the question “is this not your package?”. Well, or a router and a switch as examples of similar behavior. - vitidev
  • @vitidev no, you are mistaken. Bus does not necessarily mean broadcasting. Examples of non-broadcast tires from the world of iron - PCI-E, USB. - Pavel Mayorov
  • one
    @PavelMayorov Incorrect analogy. We are not talking about iron, where the tire is what goes somewhere where the data goes, but about the approaches of message delivery and programming, the difference in the method of addressing these messages and who does it. Of course, in programming, the tire also will not interrogate everyone, it will simply know who what type of package expects and delivers only to them. - vitidev

1 answer 1

In the article "a little" they made a mistake with the definitions, hence the misunderstandings. The fact is that the article was written, in fact, about one specific solution - and everything else is given for general information only.

An integration bus is primarily a messaging environment that allows you to deliver messages based on logical features. Fingerprint, which means that the messages themselves do not contain any physical addresses.

The simplest variants of integration buses hold the directory of logical and physical addresses. Logical addresses are formed based on the purpose of the application, its name or organizational structure. This is enough to be called a tire :)

More sophisticated options make it possible to deliver messages through the pub / sub system (publisher - subscriber).

The integration bus can be built around a central node (or several nodes) where the router “turns” (see below) - or be distributed, existing as a heap of adapters (see below) on the side of each application with a common address base.

A message router is an application whose purpose is to transfer messages from one application to another.

Typically, a message router can be found inside the integration bus — but not every router forms a bus around itself. At a minimum, you need to work with logical addresses.

Also, message routers sometimes implement other infrastructure services, such as guaranteed delivery, message logging, or format conversion.

An integration gateway is a messaging router whose communications can be divided into “external” and “internal”.

These links can work on the same protocol — in this case, the gateway’s sense is to partition a common bus into segments in order to add fault tolerance or security. For example, if there are branches in different cities, you can “put” a gateway in each one, which will transmit messages to the head office via an encrypted channel.

In this case, the common integration bus will be broken into segments that can continue to function in a limited way when the Internet channel falls.

In addition, the integration gateway can connect applications running on different protocols - in this case, it will also be an adapter.

An adapter is a message router whose different connections work according to different protocols.

Broker is a message router of increased complexity. For example, it can work with a decentralized bus. Or perform clever transformations, acting as a universal central adapter.

As you can see, none of the terms exclude others. It is quite possible to imagine the happiness of the perfectionist architect in the form of a mega-integration bus built on the message router, which is a broker, gateway and adapter. He will be able to work under any protocol, make SQL queries, perform XSLT transformations - and will become a nightmare for any developer :)

Once I wrote my integration gateway simply because for 2 months CROC refused to provide our subsystem with a second address on its integration bus ...

And from here there is one more conclusion: you can call any rather complicated program with any word. Therefore, so that colleagues understand you - try to call it those words that are used in the official name of the program.

For example, WebSphere Message Broker has the word "Broker" in its name (and deservedly wears it for its exorbitant complexity of steepness) - therefore, it is necessary to call it a broker, and not a message router, adapter, gateway or bus.

On the other hand, if, on the basis of WebSphere Message Broker, you made your own project for working with SMEV, which was called the "gateway for working with SMEV", then you need to call it a gateway, despite the fact that it is also an adapter and a message router .

Or, for example, SMEV itself is in fact the simplest integration bus, and it is spinning on WebSphere Message Broker (I saw typical error messages for it) - but you should call it SMEV, but they will not understand it.