Monday, April 30, 2007

BizTalk Vs Windows WorkFlow Foundation

Many have asked me this question – “ Now that .NET 3.0 framework is out, does it mean that we are seeing the end of BizTalk server”.My answer is always the same, “ you are comparing apples to oranges. You are Comparing a framework to Server”.

In the current posting I would like to elaborate it.

Framework/Platform Vs Commercial product(Server)?

First of all, what is the difference between a framework and a server. I went to google to get a good definition for them. I found the following…

software framework:

“A software framework may include support programs, code libraries, a scripting language, or other software to help develop and glue together the different components of a software project. Various parts of the framework may be exposed through an API.” – Wikipedia

Windows Workflow Foundation:

Windows Workflow Foundation(WF) is a programming model, engine and tools for quickly building workflow enabled applications on Windows. It consists of a .NET Framework version 3.0 namespace, an in-process workflow engine, and designers for for Visual Studio 2005. WF is available for both client and server versions of Windows. WF includes support for both system, workflow, and human workflow across a wide range of scenarios including: workflow within line of business applications, user interface page-flow, document-centric workflow, human workflow, composite workflow for service oriented applications, business rule driven workflow and workflow for systems management.” – Microsoft MSDN.




BizTalk Server:

“A server, is an application program that accepts connections in order to service requests by sending back responses. Microsoft BizTalk Server is a server product by Microsoft which provides the following functions: Business Process Automation, Business Process Modeling, Business-to-business Communication, Enterprise Application Integration and Message broker[1].” – Wikipedia.
“ BizTalk is a business process management(BPM) server that enables companies to automate and optimize business processes This includes powerful, familiar tools to design, develop, deploy, and manage processes.” – Microsoft.



So .NET framework is very generic by nature. It supplies you with set of libraries and API which you use to implement a program in your favorite programming language. But Microsoft offers a wide range of servers which are offer a solution to a very specific problem. Also, a server built using a framework in the background. BizTalk server 2006 is built on .NET 2.0 framework. That’s why you cannot compare a framework with a commercial server. Remember, I also said that – a server is built on a (using a ) framework. So a server implements or extends the API that the framework exposed.
Now, you might say – “Fine, but I still see lot of overlapping features between these, what about that?”

Feature comparison:

Let’s compare some of the overlapping features of BizTalk server and Windows Workflow Foundation( which is now part of .NET 3.0 framework) Brian Losgen’s blog has a very good comparision of the features.I went further to highlight the some of the distinctions between these:


Hosting – “BizTalk server” , like the name suggests is a server to which clients connect using a specific adapters, on the other hand “Windows Workflow” needs to be hosted in a client like ASP.NET/Windows Forms/Windows Service/Console clients. WF programs have no independent existence.

Scalability – This non-functional requirement is satisfied by BizTalk inherently. BTS provides the concepts of host instances and clustering of Message boxes. But in WF it needs to be implemented in the hosting application by the developer.

Transactions – BTS has huge selling point by providing long term and short term transactions inherently. Such feature is absent in WF. It can be implemented in the WF host by doing a custom coding.

Cross-platform integration capabilities – BTS has lot of inbuilt adapters for different transports (HTTP , FTP, SMTP etc.) , different Line of Business applications (SAP, salesforce.com, PeopleSoft etc.) and to different accelerators different market segments ( HIPAA, HL7, SWIFT etc). BTS also provides extension points for custom adapters. The goal of WF is not really about adapters management. If a custom adapter were needed then it needs to be built outside of the WF context.

Management and administration – Again BTS excels in this. It has a very robust single point of administration. It’s administration console can perform things like – Application administration, adapter management, massage flow management and lot more. But WF does not have this feature. It relies on the hosts to manage these. For example, ASP.Net hosted workflows can exploit IIS management.

Extensibility - This is one feature in which WF excels in. If a custom activity or a shape needs to be implemented then, WF provides you with the API to do it. But, BTS is far more restrictive in this. BTS can only be extended in a very specific locations.

Transformation – BTS Mapper facilitates the developer to visually map nodes from one XML format to another. Internally it uses XSLT to transform the XML. It is a very useful feature in XML based applications. But, this needs to be implemented from ground up in the case of WF.

Types of workflows – WF is a framework for building different types of work flows like – system based, human/state based, rules based workflows. BTS is famous for it’s system based workflows. I tried to find a good reason for Microsoft for not really concentrating on human based workflows, and also for discouraging the use of them in BTS. Now , I know why, because, they are in the process of using the rich features of WF. This is another indication of usage of WF in the future releases of BTS. ( BTS vNext which is going to come after BTS 2006 R2).

Business Activity Monitoring – It is a very crucial feature in an enterprise context. It monitors the analyzes the key performance indicators of critical business processes.
This feature needs be implemented out side of WF context.

And there lot of these features exclusively built in a commercial product like BizTalk. I can see that, some of the features of BTS and WF overlap. But I suggest you to visualize them as complimentary. And also remember that the features of WF are not just limited to BTS, but will be used in Microsoft’s other commercial offerings like – MS Content Management Server, MS Commerce Server, MS Share Point Server etc. But the workflows built using WF deceiving look close to BTS Workflows, because some the BTS product team also worked on WF of .NET 3.0 framework.

The following rules of thumb can be used while deciding between WF and BTS. (Taken from MSDN article - "Architecting Enterprise Loan workflows and Orchestrations").

Use Windows Workflow Foundation When:

- An application itself will host workflows. Windows Workflow Foundation lets workflow be built into an application, allowing the workflow to be deployed and managed as a native part of the application. Conversely, because it's focused on integrating diverse applications instead of providing a general workflow framework, BizTalk Server always runs orchestrations within the BizTalk Server process that is external to the application.

-The business process being implemented requires human workflow. BizTalk Server addresses system workflow, and so it lacks Windows Workflow Foundation's support for things such as state-machine workflows and dynamic update. A scenario that requires both human workflow and more complex system-integration services could be addressed by using Windows Workflow Foundation and BizTalk Server together, however. For example, the Microsoft Office 2007 support for document-centric workflows, based on Windows SharePoint Services, might be used for the human aspects of the problem, while BizTalk Server handles the system integration aspects. The two can interoperate using the BizTalk Server Adapter for Office SharePoint.

-The workflow will execute on a client system. BizTalk Server is a server-focused product, and so it's less well-suited to run on desktop machines.

Use BizTalk Server When:

- Solving an EAI problem that requires communication with diverse applications on diverse platforms. Because of its focus on cross-platform integration, a large set of adapters is available for BizTalk Server that allows communication with a range of other software. Windows Workflow Foundation is focused solely on workflow, not EAI, and so it does not provide these things.

- B2B services are required. Windows Workflow Foundation does not address this area, while BizTalk Server provides tools for working with trading partners, accelerators for Mortgage Industry Standards Maintenance Organization (MISMO), Society for Worldwide Interbank Financial Telecommunication (SWIFT), and other industry standards.

- BPM services, such as Business Activity Monitoring (BAM), are required. While the Windows Workflow Foundation tracking infrastructure can be used to create these services, BizTalk Server provides important extras, such as tools that let information workers define their own BAM views.

- A complete management infrastructure and support for increased scalability are required. Unlike Windows Workflow Foundation, BizTalk Server includes a full set of tools for administering and scaling a production environment.


Finally, couple of words of wisdom from me - "use Windows workflow Foundation for building workflows within applications.Use BizTalk for building workflows across applications”.

References:

http://blogs.msdn.com/luke/archive/2006/12/13/community-content-for-wf-wcf-and-biztalk-server.aspx
http://geekswithblogs.net/bloesgen/archive/2005/10/09/56481.aspx
http://blogs.msdn.com/chunyu/archive/2005/12/13/503382.aspx
http://blogs.msdn.com/lamonth/archive/2005/09/14/466222.aspx
http://blogs.msdn.com/darrenj/archive/2005/09/15/467838.aspx
http://geekswithblogs.net/danielcarbajal/archive/2006/09/10/90825.aspx
http://blogs.msdn.com/mikewalker/archive/2007/04/24/biztalk-vs-wf-in-the-enterprise.aspx
http://biztalkland.blogspot.com/2007/03/biztalk-or-wf-vs-biztalk-and-wf.html
http://blogs.msdn.com/scottwoo/archive/2005/10/10/479331.aspx
http://www.sharepointblogs.com/heliosa/archive/2007/02/07/19152.aspx
http://msdn2.microsoft.com/en-us/architecture/bb330937.aspx

No comments: