Database Reference
In-Depth Information
and for GoF,
http://www.eaipatterns.com/Introduction.html
). Mediator makes the senders
and receivers reference each other indirectly. There are some other traditional patterns that
implement routing and referencing, statically or dynamically, but we will stay with the
more traditional definition of Mediators. Someone can describe Mediator's core function-
ality as
Receive-Transform-Deliver
(
RTD
), which is exactly opposite to ETL), but
Transformation is not a traditional design pattern and it is mostly associated with the Ad-
apter implementation. By combining Mediator and Transformation (from Adapter, both
for Data Format and Data Models), we essentially implement the Message Broker pattern,
which is the predecessor of traditional ESBs. Practically, all hub-and-spoke integration
patterns are based on a compound Message Broker.
Due to its simplicity, it is one of the most popular lightweight implementations of tradi-
tional EAI patterns and it's not that easy to draw a line between Message Broker and Ser-
vice Broker in the SOA ESB. In fact, for the services that have strictly predefined con-
tracts (REST Services, which are based on HTTP POST/GET operations) and are exposed
as lightweight endpoints, Message Broker could be the most optimal solution from per-
formance and maintenance standpoints.
Basic relations between the discussed traditional patterns are illustrated in the following
figure:
Search WWH ::
Custom Search