Downloaded 254 times
More Related Content
Similar to Lecture 10 - Message Exchange Patterns
Lecture 10 - Message Exchange Patterns
- 1. Book Author: NicolaiM. Josuttis Chapter Ten: Message Exchange Patterns IT-Slideshares http://it-slideshares.blogspot.com/
- 2. 10.1 Introduction toMEPs There are different ways to exchange data between distributed systems. One fundamental approach to dealing with these differences is to categorize the way chunks of data are exchange. These chunks of data are called messages. By categorizing different ways of exchanging messages , we get the so- called message exchange patterns. MEPs define the sequence of messages in a service call or service operation, specifying the order, direction and cardinality of those messages. Note : MEPs are general concepts to describe communications between different systems (or nodes).
- 3. 10.2 Basic MEPs There are different approaches to categorizing MEPs. This section start with two basic patterns and explain some others based on these patterns.
- 4. 10.2.1 Request /Response Probably the most importance pattern for SOA is request/response. In this pattern, the consumer send a request message to the service provider and waits for the provider to send a response message (See Figure 10.1) From the consumer’s point of view , such a service call is like a remote procedure call (RPC) . The consumer is blocked until the response arrives. The Advantage of this pattern : Make code pretty simple. The response is delivered to the same process instance that trigger the initial request. The drawback of this pattern : You cannot do anything else while you are waiting for the response. If the provider is not available or something goes wrong , the consumer might never get the response and end up waiting forever in a blocked state. Note that you might also arrange to do something else while waiting for the response. Request / Callback pattern. (Section 10.3.1)
- 5. 10.2.2 One-Way Thereis an alternative that ‘s even simpler from a consumer’s point of view : send a message , and you’re done. This one-way pattern is often also called “fire and forget” (See Figure 10.2) The Request / Response pattern is just a composition of two one-way messages. However , this is not necessarily the case, for two reasons. From a consumer’s point of view, a combination of two one-way messages would lead to an asynchronous or non-blocking request/response (or request/callback) pattern. From an infrastructure’s (ESB’s) point of view, sending two one-way messages would require the sender of the first request to be able to receive the second one-way request (which logically is the service provider’s response)
- 6. 10.2.3 Request/Response VersusTwo One- Way Messages. If the consumer process needs the response for its further processing, it is importance that the response is delivered to the specific process instance that performed the initial request (See Figure 10.3) Example : A CRM service might need to know about a customer’s actual payment behavior to determine whether to allow a certain contract option. It calls a service of the billing system. It needs the response in order to continue to perform the initial service. So , it’s importance that the response is routed to the original CRM service instance In this case, the consumer must block and wait for the reply.
- 7. 10.2.3 Request/Response VersusTwo One- Way Messages.(Cont) With the specific initial consumer can continue to do its work without getting the response, it is not important that the response be delivered to the process instance that performed the initial request. You can consider the response message to be another service request back to the system that initiated the first request (see Figure 10.4) Example : A CRM service might enable an invoice out-site the usual payment intervals. This service might send a corresponding request to the billing system. It might call another service in the CRM system to store the new invoice number and date there.
- 8. 10.2.3 Request/Response VersusTwo One- Way Messages.(Cont) Figure 10.5 shows the corresponding sequence diagram for this scenario. You can insert message queues in your infrastructure (ESB) , so that one a message is sent it is persisted and can’t get lost. This is the core of message-oriented middleware (MOM) such as MQ and JMS. If you have no support for the request/response pattern in your infrastructure , you’ll have to program in the ability for the providing side of the requesting system to find instance to deliver the response to.
- 9. 10.3 More ComplicatedMEPs There are many possible extensions to and variations of these fundamental MEPs. This section will discuss some of the most typical ones.
- 10. 10.3.1 Request /Callback Often a process/thread needs some data or confirmation , but doesn’t need to be blocked until it arrives This pattern may be called non-blocking request/response , asynchronous request/response , or just request/callback. The consumer might define a so-called “callback function” which is a function /procedure that is called when the response arrives. Dealing with asynchronous responses usually leads to more complicated code. The response may return in a different order. his is usually by introducing correlation IDs that are passed with the requests and delivered with the responding replies. You have to make sure that the context for each response is still valid and contains all the information required to process the response. You might have to deal with the fact that no responses arrive for some requests The big advantage of this kind of message exchange is that it introduces a form of loose coupling : Service providers do not have to be available when requests are sent , and consumers can continue to work while awaiting responses. Each approach has its pros and cons It can be difficult to decide whether to use synchronous or asynchronous request/response scenarios.
- 11. 10.3.2 Publish/ Subscribe One-way messages may be sent that do not require responses. To inform another system that something has happened or changed. These kind of message are often called notifications. Following the usual business process modeling is usually to send notifications. A general design that defines that a system must notify a specific other system when certain condition arise. E.g : When a billing system has sent a new bill to a customer , a message may be sent to the CRM system to inform CRM system about a new invoice number. This is another famous pattern that enables a system to register or subscribe for certain notifications or event This pattern is usually called the observer or publish/subscribe pattern. In SOA infrastructure you often only see the second part of this pattern : The notification. The subscription might be part of the business process modeling that leads to service design. Note : at runtime , a one-way message is sent from the provider to each consumer.
- 12. 10.4 Dealing withReliability and Errors Here are some problems you might encounter when something goes wrong. The service provider detects an error and sends back a fault message instead of a typical response message. The service provider is unavailable and therefore cannot receive the message. The transport layer for the message might not be reliable. Messages might get lost over the network. Dealing with these situations can make message exchange patterns a lot more complicated.
- 13. 10.4.1 Fault Messages If the service provider (or any other process receiving messages and sending responses) detects an error, instead of sending back the usual response message , it will send back a fault message (See Figure 10.6) Usually , you can define special attributes for these fault messages. Whether and how faults are handled in special cases has to do with the protocol you use. E.g Web Services allow you to specify and deal with special fault messages that are returned by providers in the event that (expected and modeled) errors occur.
- 14. 10.4.2 Technical Errors If there is a technical problem that prevents a message from being delivered , the sender must be notified. A message exchange that is reliable from both points of view must involve a double confirmation (See Figure 10.7) With synchronous communications , these kinds of checks are usually part of the infrastructure. The sender of a message should get an appropriate exception if the message could not be delivered successfully. With asynchronous communication , things can become more complicated One typical approach is to persistently store all outgoing messages in a message queue , which tries to deliver them at set intervals. Another typical way of dealing with these situations is to retry sending the message until a corresponding response arrives. (View Note)
- 15. 10.5 Dealing withDifferent MEP Layers Message exchange pattern always depend on the characteristics of the transport layer or protocol they use. But one layer above or below, things might look totally different . E.g : You can provide asynchronous message exchange patterns on synchronous protocols ,and vice versa. Even if your transport layer is not reliable , you still can provide an API with a reliable interface (See Figure 10-8)
- 16. 10.5 Dealing withDifferent MEP Layers From a SOA point of view, the interesting issue is which MEPs the protocol supports and which MEPs the APIs support. If the ESB is protocol driven , the consumer might be responsible for programming aspects such as retries. If the ESB is API-driven , however the infrastructure team is responsible for providing APIs for different MEPs. In this case , the SOA infrastructure might provide the ability to specify the number of retries and timeout period between retries. Of course, things can become even more complicated. Example , a retry might be sent because the response took long to arrive , not because either the request or the response was lost. In this case, the consumer will have to deal with multiple responses. (Figure 10.9) Idempotency is a major concern in this scenario.
- 17. 10.6 Event-Driven Architecture What is Event-Driven Architecture (EDA)? EDA is a software architecture pattern promoting the production, detection, consumption of, and reaction to events. EDA is a technique to integrate components and applications by sending and receiving event notifications. Emitting and consumption of events Publish-subscribe pattern Asynchronous processing De-coupling of supplier and consumer Non-deterministic behaviour What is an event ? ”...a notable thing that happens...” A message signifying that an identifiable event has happened Common event information Event type specific data Event instance specific data For example, an event notifying consumers that a barrier has been placed on a phone company customer might result in all systems that deal with this customer disabling all functionality for the customer.
- 18. 10.6 Event-Driven Architecture Basic Architecture Event Processing Rules Publishing Event Processing Subscriber Services Engine Services Subscribe to event Publish event Event instance Event instance Event Subscriber Event Publisher
- 19. 10.6 Event-Driven Architecture Event processing styles : there are these general styles of event processing : Simple , stream, and complex and these styles are often used together in a mature event- driven architecture. Simple event processing - Herein, a notable event in the system, initiates certain down stream actions. For example, a simple alerting mechanism, or a message-based publish- subscribe mechanism. Stream Events Processing – Herein, applications publish a stream of events to subscribers based on ordinary and notable events. For example, RFID transmissions. Complex Events Processing – This is a more advanced form of events processing, and by definition is a high-volume, programmatic analysis of events to identify patterns and correlations across multiple heterogeneous event sources. This involves interpretation of events, pattern definition and matching, in addition to correlation techniques. For example, identification of suspicious transaction patterns in real-time, based on customer transactions. EDA is the perfect answer for systems to operate in an unpredictable and asynchronous environment. EDA designed systems facilitate more responsiveness to events that take place in real life. EDA offers a high level of decoupling, and applications must be designed to respond to and to publish events.
- 20. 10.6 Event-Driven Architecture The resulting process model The resulting process model of an EDA might be different from ( or a special case of) the process model of SOA. Instead of composing basic services into composed service or process services, you get something that can be called a “business process chain” (See Figure 10.10)
- 21. 10.7 Summary Servicesuse different message exchange patterns (MEPs) that define the order, direction, and cardinality of messages sent around until a specific service operation is done. The basic MEPs are request/response and one-way. Also important are the request/ callback (asynchronous or nonblocking request/response) and publish/subscribe patterns, and higher patterns dealing with error handling. MEPs are layer-specific. For SOA, the MEPs on the protocol and API layers are important. Events are a special type of one-way messages. They lead to event-driven architecture (EDA), which can be considered a special case or supplementation of SOA. One-way messages and events lead to (business) process chains, which is another way of implementing business processes. Instead of orchestrated services, where there is a central controller for the whole process, you get choreographed services, where each service triggers the next step(s) of the business process.
Editor's Notes
- #12 Example of Notification : At design time a service contract might define that the CRM system gets an event from the billing system each time a customer gets a new bill. Other service contracts (for example, to an online portal) might define that other systems get the same event. As a result, when a customer gets a new bill the service provider “billing system” will automatically send a notification to all the consumers with that clause in their service contracts.
- #15 With the typical way is retry sending the message until a corresponding response arrives.That is, you need to be sure that resending the message will not have unintended consequences. If, for example, you’re sending a message that adds a certain amount of money to a bank account, you want to make sure that if the message has to be resent, the effect takes place only once. If you don’t get a response to such a message, you won’t know whether it was the request or the response that failed. That is, the provider might or might not have processed the service call already.
- #16 Describe of Figure 10.8The consumer calls a service . The corresponding API blocks until it receives the response (or an exception )The protocol used is not reliable underneath this API , the code more complicated.The following steps describe sequence state in figure 10.8The first request message sent to the provider gets lost. So, after a timeout , the low-level API of the consumer performs a retry . This message is routed successfully to the service provider . Unfortunately , this time the response gets lost. So the consumer performs another retry . This attempt succeeds, and the request data is finally returned to the consumer.In this example , the consumer uses an API for a synchronous request/response MEP, while the low-level protocol is a sequence of request/callback MEPs.
- #17 The following steps describe sequence state in figure 10.9The first request message got lost.A retry was sent.The retry was successful , but because the result took to long to arrive, a second retry message was sent.This message was processed by another thread of the service provider.The consumer ended up with two responses (which might not even have arrived in the expected order).
- #18 Note There is a lot of discussion at the moment about whether EDA is a special form of SOA, an enhancement of SOA, or something different . For example, some analysts and companies have introduced terms such as “Advanced SOA” or “SOA 2.0” to refer to the combination of EDA and SOA (see, e.g., [GartnerEDA06], which strictly speaking compares and combines EDA with “interactive SOA”).
- #21 It’s like choreography (see Section 7.6): there is no central control. Instead, the process chain is a sequence of (parallel) processing triggered by events. The good thing is that there is no need for a central controlling component, which might turn out to be a bottleneck. The bad thing is that it is more difficult to understand, document , and monitor the whole process or process instances, respectively.