Undserstanding Microsoft Integration Technologies

In todays world of EAI (Enterprise Application Integration) and SO (Service Orientation) its very important to understand integrating technologies and tools that are made available to us. I always say that todays is the information world that can be thought of applications as an islands automated within themselves but not usually connected to others. And to connect them is "the task". Sooner or later our most of efforts and development time would be consumed in either integrating applications or architecting/developing applications in such a way that they are easily "connectable".

Microsoft has provided us with a number of options for architecting/designing/developing "connected applications". Microsoft has also produced a number of integration technologies. Some of these technologies are tightly integrated with data stores e.g. SQL Server Replication Services and SQL Server 2005's Service Broker(SSB), while others talk about application level integration using ASMX Web Services, .NET Remoting or COM+(Enterprise Services). And then there are MSMQ for queue based integration. To complement this all is a broker based .NET Server that we are all in love with : BizTalk Server. Not to forget INDIGO that provides a single consistent platform for .NET Remoting, XML Web Services, MSMQ, Enterprise Services etc in a "Service Oriented"

While a number of things pertaining to integration can be done in number of ways using any number of above mentioned technologies, there is no single rule of thumb for us developers/consultants to either opt for or recommend to a client when it comes to "integration" scenarios.

Just to make our lives easier Microsoft has published a white paper that i came to know about when i was visiting Scot Woodgate's Blog. I believe it is a must read for any serious developer/architect. You can download this white paper here.

ps: I am also uploading this document to DotNetWizard's yahoo group file section