Michael Poulin did a review of our SOA Design Patterns book:
Thomas Rischbeck says: “The ESB pattern is about performing integration tasks and adding value to client-service communication in an SOA – all completely transparent to the participants”. I would welcome this transparency if it were not based on intelligent routing and data enrichment having its own policies on the interaction between the participant. In SOA, we have a mechanism that regulates the interactions – Service Contract – and it is not seemed to be considered by the ESB at all.
Michaels seems to imply that the ESB doesn't honor service contracts at all. I get the impression that Michael also sees an ESB as a magical integration switchbox in the middle of the enterprise. This makes Michael feel uneasy – which I can understand very well.
There’s also another way of looking at an ESB: You could think about it as an opaque substrate for hosting "facade" services – which are fully-fledged, first-class citizens in the SOA world. Like every other service, such facade services have a formal interface (and a less formal contract which is a superset of the interface (as James Watson says. While I’d admit that there can be quibbles about business logic on the ESB – it doesn’t “break […] the service contract between the service consumer and the service provider”, as Michael thinks. The consumer wouldn’t’ reason about the actual backend provider but only about the ESB-exposed endpoint it communicates with. The rest is implementation details, so to say.
From this point of view the ESB becomes opaque. It cannot violate a service contract because it isolates whatever backend services are multiplexed through the ESB. This splendid isolation renders numerous benefits. For example, services can be normalized according to enterprise requirements; they may also enforce coarse-grain security and shield backend services from certain attack vectors. Many rings of defense is a security best practice since the middle ages.
Cheers, Thomas.
