December 2007 Archives

Communication Types Compared

|

When choosing a foundation on which to build a service-oriented system, there are a number of choices available on the Microsoft platform.  One important characteristic that all candidates must include in increasing measure is interconnection capabilities with other systems via various communication types – both standardized and proprietary.  The following table describes a number of those supported by four framework available on Windows – DCOM, .NET remoting, WCF, and BizTalk.

This little e-book on WCF channels is a must read for any advanced WCF programmer.

WF vs. BizTalk

|

Windows Workflow Foundation (WF) and BizTalk both provide workflow capabilities.  This brings up many questions.  Which should be used?  How does one make this determination?  Is WF a replacement of BizTalk?  I’m not the best person to answer these questions, but many, more qualified individuals, have already done so.  In Professional BizTalk Server 2006 Jefford, Smith, and Fairweather suggest using “WF for within your application and BizTalk Server for use between your applications” (616).  Former Group Product Manager for BizTalk, Scott Woodgate, also advises the use of WF for scenarios where the workflow will be used only within an application and recommends BizTalk for situations where a workflow will span multiple applications (http://blogs.msdn.com/scottwoo/archive/2005/10/10/479331.aspx). 

When evaluating the two, it is also important to keep in mind that, though both are centered around workflows, their intensions are fundamentally different.  WF is a foundational building block used to create systems in a way that separate processes from application code.   On the other hand, BizTalk is an enterprise-caliber platform for building service-oriented applications.  WF provides an API that developers can use and build upon while BizTalk offers a number of prebuilt components that almost all enterprise-caliber service-oriented systems need.  For instance, BizTalk provides adapters to integrate disparate systems, a durable, transactional message store, orchestration abilities, message transformation, a business rules engine (BRE), a scalable architecture, monitoring and management functionality, administrative tools, and a proven history with thousands of successful installs.  Each of BizTalk’s features that are absent in WF must be implemented by end users; even the ones that it does include (e.g., the BRE), must be tested, built upon, supported and scaled up by its users.

As posted elsewhere on the Internet, the following table further compares these two technologies:

Feature

BizTalk

WF

Hosting

Server-side in the BizTalk process

Hosted in a custom application (client-side execution, but the client could be an ASP.NET application)

Designer

Included in Visual Studio

Included in Visual Studio, or custom designers can be written

Scalability

Well-proven, highly scalable

Developer must implement

Transactional integrity

Long running and atomic (ACID) transactions

Developer must implement

Tracking infrastructure

Comprehensive Business Activity Monitoring infrastructure provided

Simple framework pieces provided that allow you to build the tracking infrastructure

Runtime modification of "in-flight" workflows

No, workflows are defined at design time

Yes, but developer must implement

Cross-platform integration capabilities

Extensive adapters available

Not supported natively

%