Once in a while, as an integration architect you’ll get into discussions with customers about the infamous synchronous versus asynchronous integration topic. When integrating a frontend (let’s say, SharePoint Enterprise Portal) with (a combination of) backend system(s), people tend to complain about the fact that BizTalk Server cannot handle that integration in a synchronous fashion. That is, from frontend to backend all integration is handled within one request-reply thread, in order to have the lowest latency possible.
In practice, pure synchronous integration is however not possible – with any integration layer. It is in fact a myth.
You know why? 99% of all transactions are ending in database queries (CRUD; create, read, update, delete) and these queries are executed by database engines, which by their very nature are doing their job asynchronously. The database client layer is asynchronously connected to the server layer. Therefore, pure synchronous integration is not possible at all.
Of course that could sound to some people as a lame excuse, but I often use it to illustrate the issue.
Now, how can we implement BizTalk as an ESB, to act as an abstract integration layer without adding too much latency? BizTalk in these cases actually works in a “synchronous over asynchronous” fashion, and by properly tuning the hosts or host instances in which these integration processes are running, BizTalk can provide near-realtime latency in a scalable fashion. The latter is important to notice, because this is almost impossible to accomplish without using an (asynchronous) integration layer inbetween, without overrunning the backend systems.
A nice topic for Myth Busters? 🙂
Cheers, Gijs
indaField 