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