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.
- Transformations
- Bindings
- Ports/Adapters
- 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.
(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:
IMO the big ‘downsides’ to BizTalk are:
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.