Service Bus-based design of SOA

In the above, we mainly introduce the concept of SOA, what is called "service" and what characteristics should be provided by "service". In this article, I'll cover a very common design practice for SOA-based on service bus design.

The design based on service bus

Based on the design of the bus, it draws on the design idea of the computer's internal hardware (transmitting data through the bus). In the distributed system, the different subsystems need to realize mutual communication and remote call, the more direct way is "point-to-point" communication mode, but this will expose some obvious problems: tight coupling between systems, configuration and reference confusion, service call relationship is complex, difficult to unify management, There are incompatibilities between heterogeneous systems. And the bus-based design is to solve the above problems. As a central system, the bus provides a unified service entrance, and realizes the functions of unified service Management, service routing, Protocol conversion, data format conversion and so on. This makes it possible to effectively connect different systems and significantly reduce 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, it is a common decoupling way to add a "third party" between the two that already exist (reference or call) relationship, 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 seen 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 inquire and look at the room, and finally find the landlord to sign the contract, and so on; second, you can also directly find real estate agents nearby, say our requirements and budget, please intermediary directly help us to fix everything. Obviously, the first way, you need to have a good understanding of the goal and also 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 what needs to complete the rental, even do not need to know which Community has a house, Who is the landlord to wait for this information (relying on abstraction, and decoupling through a third party). Of course, looking for an intermediary, although convenient, will also incur additional economic costs. Similarly, invoking a service through a broker can also 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 result is returned immediately after the message is posted, without waiting for the remote system to return to execution successfully, which can greatly increase 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 masks the details of the underlying communication between systems, and is a typical (asynchronous) loosely coupled architecture.

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 are dozens of or hundreds of systems (which are common in the insurance and financial sectors) and will become difficult to maintain. By introducing the message middleware, we can solve these problems effectively. Between different systems, only need to connect to the message bus, can guarantee the successful delivery/reception of messages. For the message-post (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), just focus on the message about yourself, 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. The Employee performance Bonus Management system subscribes to the message subject, receives a message notification to start processing (to Zhang San to perform bonus operations), and the invoicing system will immediately update the quantity of merchandise inventory after receiving the message notification. This enables loosely coupled, asynchronous communication between heterogeneous systems. Of course, the real scene may be more complex than here, but the idea of implementation 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). Among them, the Publish/Subscribe model draws on real-life Publishers (publishing Books) and readers (subscribe to books), the message of consumers (readers) only need to subscribe to their own interest in the message (book), the message producer (publisher) produced (published) Consumers (readers) interested in new News (book), will inform the consumer (reader) to accept the processing. In the JMS Publish/subscribe model, messages are typically identified by topic (subject), which is a one-to-many pattern, meaning 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 and is a one-to-one 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 the producer and the consumer are clustered, it is often necessary to combine the two patterns in a much more complex situation, with complex issues such as fault tolerance, load balancing, message consistency, message prioritization, and so on.

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:

L Scalability

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

L Low Complexity

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

L 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.

L Loose coupling

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

L 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 and system integration of traditional enterprise applications (for example: telecommunications, insurance, finance and other industries). Because the bus-based model is a centralized architecture, the bus itself is prone to form performance bottlenecks, and the complexity and cost of achieving high availability and fault tolerance are relatively high. Therefore, this mode is not very suitable for high-concurrency, high-performance, high-throughput Internet applications.

Note: There are many knowledge points about message bus (message middleware), and there are many more in-depth and complex details in practical application. Due to the length of the problem, the author does not do too much detail introduction and development, interested readers, you can consult the relevant information or reference to open source products, do in-depth study and research.

ESB products mainly include: open source Mule ESB, ServiceMix, JBoss ESB, commercial Oracle ESB, BEA aqualogic Servicebus. NET field of Nservice Bus, Masstransit and so on.

MQ products mainly include: ActiveMQ, Rabbitemq, ZeroMQ, ROCKETMQ, Kafka, MSMQ and so on.

Service Bus-based design of SOA