SOA Service Bus Design

Background

Based on the design of the bus, the design idea of the internal hardware of the computer (transmitting data via the bus) is borrowed. In distributed systems, there is a need for mutual communication and remote invocation between different subsystems, the direct way is "point-to-point" communication mode, but this will expose some obvious problems: the system tightly coupled , configuration and reference confusion, complex service invocation relationships, difficulty in unified management, incompatibility between heterogeneous systems, and so on. The bus-based design is to solve the above problems. As a central system, the bus provides a unified service entrance, and realizes unified service management, service routing, Protocol conversion, Data format conversion and other functions. This enables the efficient connection of different systems and greatly reduces the complexity of the number of connections (each subsystem only needs to be connected to the bus) and the inter-system connectivity topology.

：

Service-bus-based design often requires an ESB (Enterprise service bus, corporate services buses) product to act as an infrastructure. The ESB uses a "bus" pattern to manage and simplify the integrated topology between applications, and to support the dynamic interconnection of applications between messages, events, and service levels, based on widely accepted open standards. An ESB is an integrated approach to the standard between loosely coupled services and applications.

In its internal design and implementation, it is often applied to some classic architectural patterns, such as broker mode, message bus mode, Pipeline filter mode, publish subscription mode, and so on. Here, we will focus on these core architectural patterns.

Broker mode

The broker can be seen as part of the service bus, typically applied to the scene of a synchronous invocation (blocking after the service is invoked, waiting for the remote service response to complete before returning the result). A broker can be seen as a proxy, a distribution, and a call to a service that can be done directly through the broker. In software architecture design, adding "third party" to an already existing (reference or call) relationship is a common decoupling method, obviously, broker is no exception.

As shown in the following:

To further deepen the reader's understanding of the broker model, here are some examples:

In real life, we need to rent a child (can be regarded as a service call), can be done in several ways. First, we can first understand on the Internet, and then run to the target community to ask and look at the room, and finally find the landlord sign the contract, etc. second, you can also directly find real estate agents nearby, say our requirements and budget Ask the intermediary to help us get everything done. Obviously, the first way, you need to have enough knowledge of the goal and to find the landlord to sign the contract (depending on the specific, can be regarded as tightly coupled), and the second way, just need to tell the intermediary need what to complete the rental, even do not need to know which Community has a house, Who is the landlord waiting for this information (dependent on abstraction, and decoupling through a third party). Of course, finding an intermediary is a hassle, and it can also generate additional economic overhead. Similarly, invoking a service through a broker can incur some overhead.

Message bus mode

There are three basic components of the SOA system: The message bus, the information transformation/processing engine, and the repository. In general, these components are integrated into the ESB, where the message bus is the most important. The message bus is primarily used in asynchronous communication scenarios where the message is returned immediately after delivery. Without waiting for the remote system to return to execution successfully), it can greatly improve the response speed and system throughput. Of course, the message bus also supports synchronous communication mode. In the design of message bus mode, message middleware is a typical (asynchronous) loosely coupled architecture that shields the details of the underlying communication between systems.

In the enterprise, with the gradual development of the business, the interaction between the major systems becomes very frequent and the relationship is complex.

Imagine if there were dozens of or hundreds of systems (common in insurance and finance) that would become difficult to maintain. These problems can be solved effectively by introducing the message middleware. Between the different systems, only need to connect to the message bus, can guarantee the successful delivery/reception of the message. For the message Drop (producer), There is no need to care about what the recipient (consumer) of the message is, or how the consumer will handle it after receiving the message. For the recipient (consumer), only need to focus on their own messages, receive the message and make the appropriate processing.

As shown in the following:

More typical application scenario: Zhang San in the CRM system entered a customer contract order information and after the audit, the CRM system will send a message to the message bus (the message contains the necessary information, such as employee ID, order number, product number and transaction amount, etc., The CRM system does not care what systems will accept the message. Employee Performance Bonus Management system subscribed to the message subject, received a message notification to start processing (to Zhang San Execution bonus operation), while the invoicing system received a message notification will also be updated immediately after the quantity of merchandise inventory. So, It realizes the loose coupling and asynchronous communication between heterogeneous systems. Of course, the real scene may be more complex than here, but the implementation of the idea is similar.

After understanding the above examples, it is necessary to understand the widely used and implemented JMS (Java Messaging service) in Java EE.

JMS is a specification of messages, and the industry's popular ACTIVEMQ is the open source message bus that implements the JMS specification.

JMS supports two modes: Publish/Subscribe mode and queue mode (point-to-point mode). where the Publish/subscribe model draws on real-life Publishers (publishing Books) and readers (subscribe to books), the Message consumers (readers) only need to subscribe to their own interesting messages (books) can, News Producers (Publishers) produce (publish) new messages of interest to consumers (readers) and inform the consumer (the reader) to accept processing. In the JMS Publish/subscribe model, messages are typically identified as topic (subject), which is a one-to-many pattern. means that the same topic can be subscribed to and consumed by multiple consumers at the same time. In the JMS queue model, the message is typically identified by the queue name, which is a one-to-two model, meaning that the same message can only be received and consumed by a single consumer (and consumed only once). In an environment where both producers and consumers are clustered , it is often necessary to combine the two patterns, and the situation is much more complex and requires a complex set of issues such as fault tolerance, load balancing, message consistency, and message prioritization.

Industry-leading message bus (message middleware) products that generally support advanced features such as message filtering, automatic retry, distributed transactions, persistence, message prioritization, message backtracking, (producer/consumer/middleware itself) clustering, failover, and more.

Summarize

The main advantages of the bus-based architecture are:

Scalability

With the message schema, you can add or remove apps without affecting existing apps.

Low complexity

Each application only needs to communicate with the bus, with only 1 connection points, reducing the complexity of application integration.

Flexibility

For application communication groups that make up complex processing, it is only necessary to change the configuration and control the routing parameters to meet the business logic or requirements changes without changing the service itself.

Loose coupling

The application communicates directly with the message bus and is not dependent on other applications, so it can be replaced and modified.

Scalability

Multiple applications can be attached to the bus, concurrent processing, to achieve the purpose of load balancing.

The bus-based model can be oriented to homogeneous and heterogeneous systems (cross-platform). Currently, it is mainly used in the integration of traditional enterprise application and system integration (for example: telecommunications, insurance, finance and other industries). Because the bus-based model is a centralized architecture, the bus itself tends to form a performance bottleneck, but can be scaled horizontally Then add LVs on top of it to load balance, achieve high concurrency, high availability.

SOA Service Bus Design