Future of Send/Receive Ports

Today I attended a session on the Windows Workflow enhancements included with .NET 3.5. Two new WF shapes were introduced for sending messages to other workflows or WCF services. These two new shapes are the send and receive activities. Here is a link to a good article on these enhancements: http://msdn.microsoft.com/en-us/magazine/cc164251.aspx. In the BizTalk world, processes are defined using the orchestration designer and the send and receive parts of the process are defined on sides of the designer windows and are connected visually with lines that correspond to the send and receive activity shapes. Here is an example image which shows these lines: http://www.traceofthought.net/content/binary/btmsmq.jpg. From a visual perspective, if you have a lot of send and receive ports, especially in scenarios where you are sending lots of messages or multiple messages from a single send shape, there can be a lot of lines all over the design surface which can get messy very quickly. In fact, the lines can become a huge distraction in designing an orchestration. In .NET 3.5 the send and receive activities use arrows to denote the messaging direction rather than using connective lines. While the connective line does provide a visual cue in the orchestration designer whether the port is setup properly, I think not having the lines is much cleaner and more manageable.

 

The ContextExchange class was talked about and I got a glimpse of how context properties are receivable through the Inner Channel (Context Channel) of this class. This is an important BizTalk feature I was looking for a replacement feature for. Here is a good powerpoint that describes this: http://download.microsoft.com/download/5/8/1/5810d618-361f-4f47-943c-b20c0d420178/DEV340.ppt.

 

I also learned that the WF workflow instance Id is important for calling back into a long-running WCF service marked with the DurableService attribute. The thing to know is that this Guid value must be stored somewhere in a custom application because the WF infrastructure will not provide a built-in location for this. Use of this value when passed back into a method of a long-running process will activate the dehydrated (persisted) workflow instance.

 

Thanks for tuning in about my TechEd sessions!