Does everything go through the bus?

Question

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.

Answer 1

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.

Answer 2

As is often the case there are different ways to look at this - If you're looking at it simply from a bus perspective (something I don't fully favour) - then using BizTalk for non-aggregate/composite services has very little value (and, as you've mentioned) you're adding latency etc. Of course, even at this case one can argue for all those service BizTalk gives you such as monitoring, administration, scalability etc, but it's hard to judge how much these are relevant without knowing the full scenario.

However, BizTalk is also (and some would argue - primarily) an integration engine and is often used to mask a consumer from a service implementation.

Here's a possible scenario (again, not knowing if, and to what extent, that applies to your case) - you have a legacy app, which you're wrapping in a service to enable SOA. 18 months from now you finish implementing the replacement service, but that has a different interface (as it has more features) - if you have BizTalk in the middle you have a layer where you could poitentially map the old format provided by the caller to the new format required by the service and vice versa on the response. this means that you don't have to change all your client app (at once, anyway).

So - the answer is, I guess - it depends.