WSS Adapter webcast recording is now available on Microsoft Betaplace

I mentioned before that I’ll be doing a webcast on the Windows SharePoint Services native adapter included in BizTalk 2006 (see SeptemberWSSAdapterWebcast).


The “BTS 2006 Windows SharePoint Services (WSS) Adapter Deep Dive” webcast is now available on the Microsoft Beta Place http://beta.microsoft.com/ , Microsoft BizTalk Server 2006, under the Additional File Downloads section.


If you haven’t signed-up already in the BizTalk 2006 Beta program, then go to bts2006beta to see the instructions.




[April 18, 2006] The BizTalk Betaplace is closed now.

The videos are shared on this SharePoint site: http://wssadapter.members.winisp.net/default.aspx, in the Shared Documents document library, WSS Adapter Webcasts folder.


This posting is provided “AS IS” with no warranties, and confers no rights.
Use of included videos are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm. Some of the content was developed for the BizTalk Beta builds, but it is still generally applicable to the RTM version.

Dave Green is blogging…

Dave Green has started his blog, welcome Dave!. Dave is the WWF Architect, and he’s been having stacks of fun building out Microsoft’s workflow platform, I have to say WWF looks really cool. Dave’s a very smart cookie and has been building workflow engines for some time now, I’m sure he’ll share some interesting insights around the workflow space. Dave, John and myself were the British faction in the BizTalk team before I defected back to Blighty!

MS-BRE: Here are the results for my port of Peter Lin’s tests

For those following the debate on the implementation of the Rete algorithm in the Microsoft Business Rules Engine, you may be aware that I undertook to port some CLIPS/Jess tests provided by Peter Lin to the MS-BRE and to publish the results.   This follows on from the original article I published here.


My results for the ported tests are documented here.   They show virtually identical scaling behaviour between Jess and the MS-BRE.


There has been further debate about this on The Server Side .NET site, which can be read here.

BizTalk Rules engine scalibility

When exploring different rule base vendors, you probably encounter references to the RETE algorithm by Charles Forgy. This algorithm has proven itself to scale well for very large ruleset.
In all my years of experience, I’ve never encountered a client with more than 500 rules in a single rule policy. The reason is not any scalability issues on inference engines. The reason is simple. It is difficult for a business expert to

  • manage a very large rule policy
  • maintain a very large rule policy
  • verify and validate a large rule policy

As with any complexity, the divide and conquer strategy works very well. Split the large policy into smaller parts.
But for those who like to push the limits and see how well the BizTalk inference engine scales, you might like to read the article Microsoft’%u0092s Rule Engine Scalability Results – A comparison with Jess and Drools, by Charles Young.

Competitive Analysis: Choosing BizTalk Server Over IBM WebSphere Integration Server v5

This documents helps you understand the key technologies from Microsoft and IBM in the integration space.  It then compares and contrasts the various products and technologies.  The goal of the document is to provide you with apples to apples comparisons and endeavours to be factual and straight forward.  This document will be posted on microsoft.com shortly.  You can read it first here.


All comments welcome. Fixed the URL…

Design Contest Entry – Dynamic Transforms in Biztalk Server 2006

I should start by saying I was much happier with last year’s entry.  Last year, I used an Orchestration to limit other running Orchestrations.  It could be configures on the fly using the Rules Engine.  I should note that in Biztalk 2006 you will now have the ability to limit running Orchestrations since you now have per-host configuration. 



Since last year I didn’t place in the top 5, I decided to take a difference approach this year.  I decided to take a look at something simple and build on that.  So, I picked mapping.  Simple, right?



Transforms are a critical component in nearly every integration project.  The Transform design pattern is largely taken for granted since mapping is a relatively straight forward process.  The importance to a well thought out Transformation Approach is soon understood when messages start failing inside pipelines, when existing maps need to be updated, and when new maps need to be deployed. 



What if a truly dynamic Transform mechanism existed that could be configured at runtime, had no dependencies to outside assemblies, and handled exceptions? 



Key Features Demonstrated



  • Dynamic Transform inside an Orchestration

  • Untyped Receive and Send Ports

  • Direct Binding to the message box

  • Per-Instance Pipeline components

  • Effective Exception handling


Download: Dynamic Transforms in BizTalk 2006



To set up and run the sample, just unzip the download to the C:\ drive.  Then, follow the set-up instruction inside the DynamicTransformswithUntypedMessages.doc inside the DynamicMaps folder. 


 

Dynamic Transforms in BizTalk 2006

This sample built for the Biztalk 2006 Design Contest shows how a per-instance custom pipeline can be used to set the map name in a message. Then, the message can be mapped dynamically using an Orchestration. This allows for a consistence approach to transformation and exceptions. Set up: Just extract to your C:\ drive and follow the instructions in the Word document.

This sample will also work with BizTalk 2006 and BizTalk 2006 R2.

Get more information from the original blog post on this topic: http://www.biztalkgurus.com/biztalk_server/biztalk_blogs/b/biztalk/archive/2005/09/19/design-contest-entry-_2d00_-dynamic-transforms-in-biztalk-server-2006.aspx

BizTalk Server 2004: The great MS Business Rule Engine Debate

I have had some fun in the last couple of weeks debating the Microsoft Rules Engine with Peter Lin. Many people in the BizTalk community will know that Peter used Amazon and The ServerSide site early this year to launch an attack on Microsoft’s representation of their rules engine.You can read the original thread here. Based on a BizTalkperformance whitepaper, the latest version of which is here, and on the documentation of the Rules Engine on MSDN, he deduced that that the engine does not implement the Rete algorithm correctly, does notsupport forward chaining inferencing and does not scale. For the uninitiated reader, the Rete (Latin for ‘Net’, pronounced “Ray-tee” according to my Latin-English dictionary, or “Ree-tee” if you believe everything you read on the Internet).algorithm is the most commonly used algorithm within inferencing rules engines, and implements a number of important optimisations by establishing, at runtime, a directed acyclic graph of memory nodes to representa rule set, andretaining information about matches as data (‘facts’) pass through the nodes.


At the time, Scott Woodgate had some involvement in the debate, and confirmed that the Microsoft Business Rules Engine does indeed implement the Rete algorithm (see his comments here). I regretted, at the time, not challenging Peter’s assertions, and over the months have had it in mind to tackle the issue at some point. My opportunity came a few weeks ago when the issue arose again on the TSS site. There has followed a debate in which I have chiefly aimed at showing that Peter has no grounds whatsoever for the claims he makes.You can read the threadhere. I cannot (and really don’t need to) ‘prove’ that Microsoft has implemented their engine correctly, but I can and doshow that the performance figures published by Microsoft provide no evidence of an incorrect implementation. To this end, I have published the results of some simpletestshere. Peter has also raised a number of concerns based on the documentation of the rules framework API, and has also highlighted the “side effects” feature. I do admit the the “side effects” feature is ‘impure’, although I consider it a very practical feature, but I contest that it somehow invalidates Microsoft’s implementation. Other API issues, such as Peter’s recent comments about the Assert class (see here), are based on a fundamental misunderstanding of what he is reading on MSDN.


If you enjoy this sort of stuff, do please feel free to read and join in the fun!!

Take A Look At The BizTalk Server Solution Designer

There is a 52 minute video on BizTalk Solution Designer.  If you do not have a full 52 minutes to devote to this, you can get a good feel for the tool in the first 15 or 20 minutes. 



BizTalk Solution Designer is a visual tool for Biztalk Development.  It abstracts the whole process of building port, locations, pipelines, routing, and more into a visual tool. 



This new tool is targeted toward the business developer but is will not be available any time soon.  It will not be available until after Biztalk 2006 is released.



They showed some of the prototypes that this tool could have looked like.  I liked the Saturn design myself…


 


I really wanted to see the new XSLT visual mapper.  I think mapping in an integration solution is under valued (i.e if the map is wrong or does not work the whole solution is worthless).  But, they did not cover it. 



If they keep making BizTalk development so easy, they are going to put me out of a job.



You can get more details from Scott’s post or go directly to the Solution Designer Video.



Channel 9 also has a Windows Workflow Video available too.


 

BizTalk Server Futures: BizTalk Server Solution Designer

We had a bunch of fun recording this video for channel 9 on the BizTalk Server Solution Designer which is coming after BizTalk Server 2006 and was shown to folks at PDC along with a demo of Windows Workflow Foundation in an ASP.NET web-site talking to BizTalk Server (its pretty simple stuff you use web-services or the sharepoint adapter and all is good).  Anyways I hope you enjoy the video of the BizTalk Server Solution Designer. 


To view it click here.