Browse by Tags

• BizTalk;Vista;WCF;Web Services;WinFX;Workflow
• BizTalk;WCF;Workflow
• Vista
• WCF
• WF
• Workflow

• The Future of BizTalk/WCF/WF

  Walter Michel commented on my recent entry on the BizTalk and WCF Messaging Models and asked if I had some guesses as to what the architecture of a future BizTalk version might look like in regards to WF/WCF integration. I think that, at this point in time, it is anybody's guess what it might look like, as it is just too early to tell. Honestly, I don't know what it might end up looking like, and I can't even say I can make an educated guess (and there are people with far more criteria for making such educated guesses than me, such as Jon Flanders ). Instead, I'll address the question in a different way, by mentioning what I consider a few challenges I see regarding the integration and other things like that. The Impact of Significant Architecture Changes One key aspect of the whole integration process between the three technologies is what the impact of significant changes to the core BizTalk architecture. Microsoft already went down that path during the transition between BizTalk 2002 and 2004, and while those of us developing BizTalk solutions are extremely grateful for the benefits that the new architecture brought over, companies with large investments in BizTalk 2000/2002 solutions were not so happy. For most of them, going to BizTalk 2004/2006 meant a complete rewrite of their integration solutions, and that can be very expensive, and though to justify to the business side, not only because of cost, but also because of the associated risks. With BizTalk 2004/2006, BizTalk brought over not only a significantly revamped platform, but also a new, effective, and very welcome extensibility model that has been tested with time. That's why the current core product architecture has been good for three release cycles already, and the fact that even complex things like WCF could be integrated without significant changes to it is pretty substantial. A lot of Microsoft clients and partners have made significant investments in that architecture and its not clear how that investment might be preserved (or at least their loss mitigated a bit) if significant architecture changes happen. I'm pretty sure the people at the Connected Systems Division at Microsoft are aware of this, and from my own, outside perspective, I can only say that it seems like a daunting and complex decision to make. Whatever way they decide to go, it's not going to be easy. So, what happens if the complex changes do become a reality? We can only hope that good migration tools are not left by the side; but even with those migration tools, you'd probably be looking at a complete rewrite scenario again for the most part. Messaging In my previous entry, I commented that the current WCF integration in BizTalk 2006 R2 leverages the existing BizTalk messaging extensibility model (the adapter framework) on top of the messaging engine. However, I think that in the long run, keeping both is probably not the best solution. Despite their differences, there's still a lot of common ground and responsibilities Read More... Posted Monday, September 03, 2007 7:55 PM from Commonality - Workflow | (Comments Off) Filed under: Workflow, BizTalk, WCF

• Workflow Services in Orcas

  One of the new power features in .NET 3.5, sorely missing when .NET 3.0 was released is the integration between Windows Communication Foundation and Windows Workflow Foundation, in the way of the new Workflow Services model. Besides providing an easy way to invoke WCF services from WF without resorting to using BasicHttpBinding on the services or invoking a [wrapper] client class form a code activity in your workflow, it also provides a way to expose a workflow as a WCF service to the outside. The second functionality is the one that, naturally, interests me the most. After looking at it for a while, I've made a few observations that I'd like to share. Implementing Services A very interesting thing is how you implement services as workflows. If you know how to create WCF services the right way, then you [mostly] know how to implement services as workflows. The reason for this is that most of the tasks you'd normally when creating a WCF service still apply when creating a workflow service. That is, you will still declare your service contract (interface) as well as your message/data contracts. The only key differences really is how you implement that contract. When using workflow services, you implement a contract by using the new Receive activity introduced in .NET 3.5, and select which operation of the contract you'd be implementing. You still need to do the activity binding dance for parameters as well as (possibly) create response messages for the incoming requests. Basically, the Receive activity works as a kind of sequential activity where the child activities represent the tasks to execute after the request message is received until the response message is sent (if this is a request/response service). You'd also need to do a lot of the usual work in setting up your service host, only instead of using the regular ServiceHost class you'll be using the new WorkflowServiceHost class. Guy Burstein has a good entry on getting started on exposing workflows as services here you might want to check out. Starting Workflows One very interesting option in the Receive Activity is the CanCreateInstance property. You can use this property to have the WorkflowServiceHost automatically create and start a new instance of your Workflow when a new message arrives at the service endpoint for the implemented operation, without having to write manual code to receive the message and create the new workflow instance. People familiar with BizTalk 2004/6 will recognize this option as being similar to the Activate property of the Receive Shape in BizTalk orchestrations. It also serves, in a way, a similar purpose as the CanCreateInstance property of the new [DurableOperationBehavior] attribute introduced for WCF in .NET 3.5 as part of WCF Durable Services infrastructure. Jesus Rodriguez has an excellent article introducing this new feature. Something I found a bit curious about the CanCreateInstance property of the Receive Activity is that there's currently no validation Read More... Posted Wednesday, June 27, 2007 11:24 PM from Commonality - Workflow | (Comments Off) Filed under: Workflow, BizTalk, BizTalk;WCF;Workflow

• Comparing the Workflow Rules Engine to the BizTalk Business Rules Engine

  Back in November I delivered a presentation to the Twin Cities BizTalk User Group titled 'Rule Engines: Workflow Rules vs. BizTalk Rules'. Since then I have been working with the Rules Team in Redmond and with their input I have updated and added content to that presentation.  Hopefully the presentation will help you when you get questions about how the Workflow Rules compare and relate to the BizTalk Rules Engine. Posted Wednesday, March 21, 2007 12:18 AM from Stephen Kaufman's WebLog : WF | (Comments Off) Filed under: WF, BizTalk

• WCF, WF and BizTalk Sample Posted

  We just uploaded to our corporate site a small sample we created for the Windows Vista Launch in Colombia, showing some features in Windows Communication Foundation, Windows Workflow Foundation and BizTalk Server 2006. The sample showcases a simple business scenario that uses features like WCF self-hosted services, multiple bindings (HTTP and TCP) and callback contracts. The service is consumed by a simple WinForms client, as well as a simple State-Machine Workflow that uses the HandleExternalEvent activity to receive events fired by the WCF service, as well as my own custom MSMQ activities to fire messages off to BizTalk for further processing. (Notice we focused on the core features and keeping the code simple to showcase them, so the sample lacks quite a bit of error handling). Technorati tags: WCF , WF , BizTalk , Vista Read More... Posted Tuesday, December 05, 2006 10:22 PM from Commonality - Workflow | (Comments Off) Filed under: WF, BizTalk, WCF, BizTalk;Vista;WCF;Web Services;WinFX;Workflow, Vista

• BizTalk and Windows Workflow

  It always comes down to choices.  The biggest part of choosing is knowing what you gain and what you give up with each alternative.  Whenever I start talking about Windows Workflow I am always asked many questions.  Typically the first question that is asked is "does this mean that BizTalk is going away?" followed by "well, then when do I use each one".   That is what I want to discuss in this blog entry.   First, BizTalk is not going away.    I want to put a definition around BizTalk to make it easier to compare to Windows Workflow.  BizTalk Server is an enterprise level workflow and message processing environment.  This environment is tried and tested (extremely rigorously over the last many years).  BizTalk also includes many adapters to connect to a variety of back end system.  Out of the box, BizTalk provides scalability, manageability, tracking, logging & administration tools.    Windows Workflow is an SDK for creating workflow based applications.  The tools are there to  build a host and to render a graphical workflow environment.  Scalability is possible with Windows Workflow but it is up to the developer to create a truly scalable solution.  In addition, there are administrative functions through runtime and tracking visibility but there is not an out of the box administration tool as this is also up to the host developer to create.   The message that I tell people is to use BizTalk when you want to target users/clients that want to span multiple applications whereas Windows Workflow would be used when you want to target users/clients that want workflow within an application.   Now after saying that I know the next question you would ask and it is "Are you saying that Windows Workflow doesn't scale?".  The answer is certainly yes, Windows Workflow scales.  Windows Workflow scales based on your implementation.  This is similar to what you would expect when scaling any application built using the .NET framework.  Windows Workflow does not come pre-built as a server application ready to scale as does BizTalk but if you develop the appropriate host and put in place the appropriate development effort then it will certainly scale.   It has been stated that in the future Windows Workflow will be the core workflow engine in all of the Microsoft products that offer workflow.  This means that future versions of BizTalk will be built on top of and extend Windows Workflow.  This also means that products like SharePoint will also offer workflow based on top of Windows Workflow.   So, to summarize, Windows Workflow is great for workflow within an application whereas BizTalk is great for workflow across applications and this is precisely why BizTalk shines in Enterprise Application Integration scenarios. Posted Tuesday, November 22, 2005 1:35 PM from Stephen Kaufman's WebLog : WF | (Comments Off) Filed under: WF, BizTalk