|
|
Browse by Tags
All Tags » BizTalk (RSS)
-
If you are coming to the SOA/BPI conference in October - consider coming two days early and hearing Aaron, Matt, and I do a deep technical presentation on all the cool new stuff coming out from the Connected Systems Division at MS. Details are here - http://www.pluralsight.com/courses/WhatsNewInCSD.aspx Check out my BizTalk R2 Training . Read More...
|
-
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 Read More...
|
-
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, Read More...
|
-
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. Read More...
|
-
Paul Andrew announced recently a coming CTP [1] that will provide BPEL 1.1 support to Windows Workflow Foundation. This will provide a set of custom WF activities that map to BPEL 1.1 constructs as well as tooling to import BPEL processes into WF XAML workflows and export the other way around. I think overall this is very good news and, as Paul says, highlights the power and flexibility offered by the domain-neutrality of the WF runtime. Paul also mentions that this will, in the end, be supported in a future release of BizTalk Server, once the orchestration engine is built on top of WF, and by that time the toolkit support should have already been expanded to provide BPEL 2.0 compatibility in both WF and BizTalk. Pretty exciting stuff which I'm sure will provide some good selling points for both products (even if many people don't use it eventually). One important aspect of this that is interesting to consider: the WF approach to writing workflows means that, if BPEL compatibility is an aspect you care about, you'll need to restrict yourself to a subset of the power of WF in order to remain compatible (and meaning being able to later export your WF workflows into BPEL). This is something I completely expected and understand (and even welcome, to a point), but it's something some people might not realize right away. [1] Am I the only one getting lost along the miriads of CTPs coming out of Redmond lately? Seems pretty imposible to keep up if you actually have a day job! Windows Read More...
|
-
Harry Pierson talked a bit about the stuff he's learning on BizTalk Server in Morning Coffee 12 entry (btw, loving them, keep it up!). Looks like he's attending a great class with Matt Milner . A few comments that sparked my interest: Harry says that conceptually BizTalk hasn't changed all that much since the 2000/2002 days. I'm not sure I'd agree, but that would depend on what he means by "conceptually" I'd say that from an architecture point of view, the the change between 2002 and 2004 was a very significant one, requiring you to adapt to a lot of new stuff. Here's why I feel this way: The orchestration engine was pretty much rewritten. The designer by itself is a great improvement, but it's far more than that: There's no more interpreted XLANG, now we have XLANG/s Orchestrations (*.odx) are compiled down to C# and then to MSIL. Now we have a pretty powerful correlation mechanism as well as convoys. Native .NET support (it is .NET after all!) The messaging model changed significantly: Most of the terminology changed. Remember channels, AICs and Receive Functions? The messaging model is now mostly symmetrical, unlike in 2000/2002 where the send and receive sides were very different. The pipeline model is far nicer (have I mentioned I love pipelines? they're fantastic!). The adapter framework. Sure beats down anything we had in 2000/2002! Writing adapters is still hard, but writing them in .NET is far easier. Application Integration Components (AIC) were a kludge, anyway. New Read More...
|
-
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). WCF , WF , BizTalk , Vista Read More...
|
-
Jon Flanders posted a comment on my post yesterday about the changes in the new release of my MsmqActivities sample regarding the new subscription persistence functionality. I was going to respond on another comment, but I think this might be important enough to warrant its own post. Here's Jon comment: I am still concerned about your approach (essentially another persistence service to take care of). Especially in light of: a) How will this work in a mulit-host instance environment b) How will it stay consistent with the state of the workflow itself (what if your service gets out of sync with the current state of the workflow). Which is why I would prefer some system that used the metadata of the activity instance itself - I would lean toward SqlPersistenceService.GetAllWorkflows - which would allow you to get the activity metadata without having to load it into memory. OTOH - this is only on the OOB persistence service. Let me just start by mentioning that I actually share Jon's concern about this approach [1]. It is another persistence service to take care of and that brings up a number of issues and potentiall problems with it. Regarding point (a) Jon brings above, the answer is: it won't work well, for very obvious reasons. The primary one is actually related to how MSMQ itself works, and that's a significant limitation right there. If you have multiple hosts trying to listen to the same queue, then things won't really work very well. And, because of this, using this in a Read More...
|
-
Eric Lee has a pretty interesting idea here of integrating Visual Studio Team Foundation Server with BizTalk Server to create a Virtual Kanban System . Pretty funky stuff and pretty cool. It sounds, though, as something where possible Windows Workflow Foundation would be an even better choice than BizTalk: It's more lightweight (certainly less expensive for this case) and would offer a more expressive environment for this kind of automation (using custom activities). WF integration for TFS v2.0 process templates, anyone? Then again, the BizTalk/WF distinction might not be needed one day :-) Technorati: BizTalk , Team Foundation Server , TFS , Windows Workflow , WF Read More...
|
-
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 Read More...
|
|
|
|