WF 4 or BizTalk 2010?

Question

I've got a question - BizTalk or WF? And let me clarify that I realize the analogous technologies behind the first three artifacts, and realize I could build them, but I don't find that they are built-in to WF and so I'm trying to understand why I would use one technology over the other.

1. Transformations
2. Bindings
3. Ports/Adapters
4. BizTalk Future

Transformations

It's quite nice that BizTalk natively supports, with enhanced designers to boot, the ability to produce schemas and maps. Further, I like the fact that everything is transformed because I don't have to worry about my integration point inside my workflow because it's always in a consistent format which mitigates my risk as my integrations mutate - I only have to refactor the schemas and maps.

In contrast, with WF, I don't have that luxury built-in so am I missing something or does BizTalk have a +1 here?

Bindings

Bindings are another fully encapsulated piece of functionality in BizTalk. I can literally set my workflow up to have any binding I want because of the aforementioned artifact meaning that during testing I could bind to a file system and during production I could bind to a service.

In contrast, with WF, I don't have that luxury built-in so am I missing something or does BizTalk have a +2 here?

Ports/Adapters

This is quite possibly the biggest artifact that exists in BizTalk - IMHO. The amount of effort it takes to abstract your physical connections into numerous concrete implementations, especially in a very large organization where some of those concrete's reach past a rudimentary file system vs. SOAP/REST and into stuff like an IBM Mainframe and MSMQ. BizTalk's physical port adapters, which automatically run the raw data through the transforms before sending the workflow the message, are quite simply, elegant.

In contrast, with WF, I don't have that luxury built-in so am I missing something or does BizTalk have a +3 here?

BizTalk Future

Finally, I would like to mention that from my research the same team of people that built BizTalk is building WF - which is great! Further, Microsoft's long term vision is this new buzz word "integration server" and is effectively a large array of loosely coupled frameworks that provide what BizTalk does today. And that effort makes a lot of sense to me because of the Azure effort - which I'm sure is contributing to that. However, I need to implement a solution today that will work 15 years from now, but I also need to understand what pieces I'll have to use to put it together if I leverage WF over BizTalk. Please provide me with your experiences.

Answer 1

(Disclaimer- my WF experience is limited to WF3.0, so I may be behind recent WF developments)

BizTalk is most suited to inter-system, inter-department and inter-company Integration + Business Process workflows (BPEL) - i.e. enterprise concerns. IMO WF has until now been positioned more toward internal system or application concerns. But there are undoubtedly increasingly grey areas as it seems both are converging toward Azure + Appfabric.

It seems that you are looking at WF for integration?

Transformations - undoubtedly a good thing in BizTalk - given that you can map either visually or directly in XSLT, you can quickly transform message formats on Ports or Orchestrations, and leave the physical technology used as an afterthought - i.e. you can implement your design at a logical level and woun't get 'bogged down' in any specific technology (MQ, WCF, SQL, FTP etc).

One caveat - management of schemas can become quite a pain - every message has a schema, which needs a unique XMLNS#Root across all Apps on BizTalk. And you can be 'agnostic' and use canonical schemas for your internal flows - so good naming, configuration and management disciplines are needed. Schema management becomes especially onerous if you are coupling BizTalk to a lot of WCF / WebService services - there will be a request and response schema for each and every service consumed (you can share common schemas if you use MessageContract).

Bindings - you've pretty much got it. In addition, if you use Direct (message box) bindings, you can choose to have multiple incoming receive locations, or send destinations by simply adding a new port with appropriate filters. This pub-sub capability forms the basis of the ESB toolkit for Bizalk. Bindings for different environments (Dev, UAT, Prod etc) is also managed nicely.

Adapters - agreed - switching from file to MQ Series is as simple as changing the port configuration. BizTalk works very nicely with MSMQ and IBM MQ.

In addition, don't underestimate the amount of effort to administer and maintain an EAI / BP solution - integration is usually mission critical to an enterprise and tracking errors and avoiding downtime is essential. BizTalk has the following operational benefits:

• Operational Management - Tracking / tracing, management of Suspended messages, SCOM integration packs, etc
• Scalability / Clustering / Failover capabilities, adapter retries, automated throttling, etc
• Business Monitoring and Eventing - BAM

IMO the big 'downsides' to BizTalk are:

• Cost
• Ramp-up time to become skilled at development (BTS has its quirks e.g. zombies and defining BAM definitions in XLS and XML files)
• Ramp up time for network / admin professionals to get skilled on operational management

Bottom line : If you are doing integration between 2 or 3 apps with a small number of noncritical messages then go a proprietary or WF route, but if you are looking at an enterprise wide solution, an EAI / BPEL engine like BizTalk would be the way forward.

Answer 2

Great post and answer.

Are people starting to see customers consider WF for integration projects now that WF Manager is available? Previously id never really seen anyone consider WF + WCF for anything other than small scale or niche areas due to the lack of a mature hosting environment. Are people starting to see that change in the real world?

Can I also add my perspective on the downsides stuart mentions. I dont agree 100% with his comments.

• Cost

Cost isnt as much of an issue as it used to be. BizTalk on Azure can change this situation for you so you can get setup with a pay as you go model. While there is still a license cost (its just per month) when you consider the range of types of solution you can build its not bad value for money. I think people often struggle to quantify the cost of a custom build solution and just assume because biztalk has got a license it must be more expensive. When people debate the cost of BizTalk I often ask why they would use Sharepoint to collaborate when they can just use a shared folder and email. I think cost is relative, for some companies it can be more than what you would get value for if you only have a couple of integration processes, but for others it can be a great investment.

• Ramp up / Dev

I agree biztalk is a specialized skill set but its not really that different to a developer on any other platform. Sometimes a company wants to put a .net developer with no experience onto sharepoint or dynamics CRM and then wonders why they make mistakes, you dont need to be a genuis to work that one out. There are some great resources out there to help you become a biztalk developer, especially compared to some competitor products, id view this as a strength over WF im my opinion. The key risk about BizTalk development is that you can easily do it really badly if you dont know what your doing. That is a common mistake in the industry but ive seen this done with other platform implementations plenty of times too

(Note on "WF as a competitor" i view WF as a competitor on a subset of what BizTalk does but longer term I think they will complement each other in some situation s too)

• Ramp up / Admin

This isnt really any different to any new product you would be introducing, your company would need to work with your IT pro outfit to get them in a position to support and maintain which ever product you used. Its not the easiest thing to get a good BizTalk admin, but there are lots of resources out there to train people up and there are partners available in this space if you want to outsource it.

While WF is a simpler product Im not so sure that the implementation side of this from an admin perspective would be a whole lot simpler. You still need a SQL Server somewhere which is going to perform really well. The WF tooling for admins is a lot less mature and I dont think the support space for WF administration is as mature.

You might want to checkout the below book which has a chapter (7 i think) on a scenario where they considered BizTalk or WF + AppFabric, some interesting discussion points

http://www.packtpub.com/applied-architecture-patterns-microsoft-platform/book#chapter_7