When the topic for discussion is Message Exchange Patterns (MEPs), the main thing under consideration is the direction and timing of information between the customer and service. Let’s discuss the four primary choices available and their implications.
The pattern Request/Response services is possibly the pattern that all are familiar with. We can all make a function call to a component at ease and wait for the response. When a service employs this pattern, it is recurrently carrying out a remote procedure call where the caller captures functionality on the remote service and is obstructed until either the recipient sends a response that the caller is waiting for or a timeout occurs. Though this is a simple pattern for the BizTalk development service personnel, but it may give rise to unethical behavior. It is perfect for mashup services and the fine-grained functions. The recent BizTalk Server versions support the tasks of consuming and issuing services abiding by this pattern.
When divulging request/response operations by means of BizTalk orchestrations, the Communication Pattern of the orchestration port is applied to Request-Response and the Port direction of communication is equivalent to the direction of the pattern. Once this orchestration port is in control of the request/response receive port, BizTalk handles the correlation of the response message with the suitable thread that sent the request. This is important for the reason that by default, the server is an entirely asynchronous messaging engine. Even if the BizTalk Server is configured in a B2B messaging request/response mode, it’s just putting a front wall on the typical underlying plumbing. In fact, a BizTalk service interface that is synchronous dominates over a complicated system of correlating MessageBox contact to conjure up a request/response pattern.
