Jesus Rodriguez started an interesting discussion here about the differences between WCF Behaviors and BizTalk Server Pipelines, focused on what the right use cases for each one are when developing solutions on BizTalk Server 2006 R2 and the WCF adapters included in it. I think this is a really interesting discussion, and one I've given a bit of thought over the past few weeks. As Jesus correctly points out, this discussion is also more important because of the changes that might ripple through the product as WCF and WF permeate the underlying BizTalk architecture as they get integrated into the core product.
Instead of explicitly talking about Behaviors Vs. Pipelines; I'd like to approach the topic from a slightly different point of view: the messaging stacks.
In BizTalk 2006 R2, integration between WCF and BizTalk is done by talking advantage of one of the key extensibility points in BizTalk: The adapter framework. In other words, both WCF send and receive facilities are exposed to BizTalk (and from BizTalk) through a set of adapters that hook the WCF model to the BizTalk Messaging Engine (and ultimately the BizTalk Message Box).
This is obviously a simplification of sorts, but the main idea is that, for this release, the BizTalk architecture itself didn't suffer significant changes in order to enable WCF connectivity. At the same time, WCF didn't need itself any changes either; though certainly a number of extensions needed to be added in order to create fully functional BizTalk our of the core WCF binding/channels. In many ways, this is a testament of the power and flexibility of the extensibility models for both platforms. On the other hand, it means that both messaging stacks are almost fully present, with all the differences and similarities they have.
What will future versions of WCF/BizTalk look like? I honestly don't know, but one can speculate a bit. An interesting thing that might give us some clues about what is to come is to examine some interesting differences between the two models. While there are many similarities, there are also some key aspects where WCF approaches things differently from BizTalk. Here are a few:
Messages
A lot of people mistakenly think that BizTalk Server is all about XML messages and that anything flowing through BizTalk must be XML. While it is true that XML messages are first class citizen in BizTalk and that many aspects are modeled around XML-like concepts, this isn't really true.
In particular, at the messaging level, when you're working with Adapters and Pipelines, messages are simply streams of bytes. What those bytes contain is really irrelevant to BizTalk; all it cares is that it can read and manipulate those streams. In fact; it's pretty easy at this layer to deal with purely obscure or binary data; though obviously some components will make assumptions about what the data should look like (example: the Xml Disassembler expects to be able to interpret the message stream as XML text).
In WCF, on the other hand, the message concept is more closely tied to XML; however, not to the textual XML representation, but rather to the XML InfoSet. This means that it is still perfectly possible to deal with other kinds of data as long as there's a component in the WCF stack that can make it look like an XML Infoset. This can be done either by actually translating from another representation into XML (say a database structure to XML) or by "faking it" (such as a binary stream with fake open/close XML tags).
In practical terms it means that, for the most part, you can accomplish the same thing in both models; though it does mean some things get done at different layers in the stack. For example, in BizTalk, interpreting message content is usually done fairly up in the stack (i.e. the pipeline, unless you have an application adapter with specific needs), meaning things like message format are only looked into until fairly late in the game. In WCF, however, these tasks are usually done very early own, usually at the request of the Transport Channel.
This does not mean that the transport channel author has to necessarily need to implement things like message parsing, but it may mean that it is his/her responsibility to ensure it gets done. For example, a transport channel will call the configured MessageEncoder to encode/decode messages into/from the network.
Message Structure
Another interesting aspects is message structure. In BizTalk Server, messages are not really a single entity. Instead, each message is composed of one or more "message parts", each one containing it's own data stream independent of the rest, with one of them being marked as the "body" of the message. Also, each message carries around a property bag [1] associated to it (the Message Context), which can be used to carry "out-of-band" data. and that is a critical part of BizTalk's Pub/Sub mechanism.
WCF messages aren't quite structured the same way. In fact, WCF messages don't quite have the concept of "multi-part messages" as clear as the one in BizTalk Server (though support for protocols like MTOM certainly make it possible) and so only really have a single, body data stream (or really, Xml feed) associated with them. However, unlike BizTalk, they also have two different ways to carry out of band data: Message Headers (obvious, if you consider that the WCF model is closely tied to SOAP), and Message Properties.
Assembling and Disassembling
Another interesting difference between BizTalk and WCF, and that Jesus already pointed to, is the fact that, in WCF, interchanges are really one-to-one throughout the WCF stack. That is, one message comes in, one message comes out.
This is rather different from BizTalk, in which the assembling and disassembling stages of send and receive pipelines respectively were created explicitly with the idea that messages might be joined or split during processing. This is why the stages are referred to using the terms assemble/disassemble and not simply as "parsing" or "translating".
On the receive side, this enables some really powerful mechanics for processing large interchanges, by breaking (debatching) messages as they come in into smaller parts that can be processed individually. Similarly, on the send side, multiple messages can be joined into a single, larger message. Unfortunately, the latter functionality is never used by the messaging engine (though it is accessible when calling pipelines directly from orchestrations).
So this is one point where there's a significant difference between the two messaging models. Certainly, nothing would prevent a WCF transport channel from implementing it's own disassembling/assembling functionality, though it might be a complex job, and likely not very reusable. It might be possible to implement it at higher levels of the channel stack as well, but I really haven't looked too closely into this, as, in general, this isn't as useful a feature in the context WCF services are normally used (but it is a very important one in the context BizTalk is used).
Channel Shapes
BizTalk Server only really has two different Message Exchange Patterns: Either you support exchanging messages in a single direction (one-way) or in both directions (two-way).
WCF, however, supports 3 different message exchange patterns (you could say the third one can also be simulated in BizTalk). The ke
y differentiating here, however, is that WCF creates, on top of these three basic MEPs, a large number of different Channel Shapes, which complement the basic interactions by separating stateless and state-aware variants. Thus, the appearance of Session-aware channels.
It's obvious that WCF's model is here quite a bit more powerful than what BizTalk offers right out of the box, though it can be argued as well that this makes the model a lot more complex (and more confusing) for channel authors. BizTalk essentially assumes that all interactions are stateless (i.e. the concept of session doesn't exist); which is partially mitigated by the powerful orchestration + correlation sets combo.
I think it will be extremely interesting to see how the concept of sessions is brought into the main BizTalk architecture in a future version as WCF gets integrated more deeply with the BizTalk messaging engine. It certainly adds a few new challenges to the decoupled, highly asynchronous interaction model between BizTalk components.
Conclusion
I don't really know what the future will bring for these two platforms, but certainly the combination of WCF + WF + BizTalk is going to bring significant changes to the platform. I have a few gut-feelings about what it may look like, but they don't even qualify as educated guesses :-). Still, it's going to be pretty interesting to see how it evolves.
[1] There's also a property bag associated with each message part; but it is used less often and isn't as important as the message context.
