We have introduced BizTalk into our organization as a Service Bus, it is linking a new Web GUI to numerous existing back end systems. We have wrapped our existing systems as Services (WCF) and connected them to the BUS.
We are also replacing some of the legacy system GUI's with our new web GUI (ensuring we replicate existing functionality) but I am curious as to whether we should expose all legacy services/api's via the BUS, connect to them directly or compose them differently and expose them via the bus. For example, lets say our Customer Management system has 5 existing services/api's, Search, Add, Retrieve, Update, Set Billing Details.
Does it make sense to expose each of these services through the BUS (some argure it adds latency)? Or should the BUS only expose the coarse grained services such as Search, Add, Retrieve & Update and not the fine grained one? Should the GUI connect to the fine grained service directly?
I am under the impression that in an ideal SOA/ESB you would compose both Update and Set billing Details into one Coarse grained service, is this correct?
I would like to stay true to the SOA/ESB paradigm, could someone enlighten me please.
Best Answer
The ESB is best applied to building "Composite" applications.
First, you have to expose a lot of fine-grained services from a lot of discrete applications.
This sets the stage for building composite applications.
The point is to create composite services that don't exist in any single application. These services only exist in the ESB. They are built from fine-grained services.
Note that the composites rely on fine-grained services, both of which live in the ESB, reducing the overheads involved in locating and executing the fine-grained services. However, the real work is done by external applications, which introduces some overhead.
Note that the performance ESB-based applications so totally defeats other methods of interaction that wringing your hands over "latency" misses the huge victory from immediate, direct integration.