WCF LOB Adapter SDK Public ‘RC’ is now available for download!


We are delighted to announce the first public RC release of the WCF Line-of-Business Adapter SDK. 


Goal of this SDK is to create uniform, reusable and metadata-based service-oriented interfaces to existing systems and applications using WCF.   It allows adapter developers to build WCF-based adapters for integrating .NET applications with existing enterprise systems, databases and messaging platforms.   This SDK includes application programming interfaces, design-time tools, samples and documentation to surface line-of-business adapters as WCF Bindings.   The WCF-based adapters can be consumed like typical WCF services in the user applications.  It is available in 32-bit and 64-bit versions.

To learn more and download the adapter SDK and its documentation, please refer to our Microsoft Connect site (you need to register using a valid passport).  

Make sure to visit our forums for additional information and community based support as well.

We’ll be recording a channel 9 interview on the adapter SDK in the upcoming month also!  J


Marjan Kalantar

Free Training DVD’s in New Zealand

Free Training DVD’s in New Zealand

How would you like hours and hours (in fact weeks) of training and sessions on WPF, Silverlight and everything Web Related?

Arturo Toledo has even given us permission to share with you the Expression Blend, Web and Silverlight Hands On Labs from MIX!

One of my favourite labs is building the Expression Blend: Color Swatch that appears in the Blend Samples.

If you live in New Zealand take a trip to http://www.microsoft.co.nz/nextgeneration and grab a copy of the DVDs (including > 20GB of love) while stocks last!

We’ll even throw in a bonus DVD of Visual Studio Team Suite 2008 (Beta 1).


Microsoft.com on Windows Server 2008?

From Netcraft yesterday

“Microsoft has recently switched its main website, www.microsoft.com to Windows Server 2008 and Microsoft-IIS/7.0.

There are already around 2,600 sites running Windows Server 2008 on the Internet. Whilst some of the servers running Windows Server 2008 are at Microsoft itself, the majority are not…”

Also there have been some more great write ups on REMIX in Aus JD, Lee, Scott

Microsoft Enterprise Service Bus Guidance – Community Email

Announcing  – June 2007 Community Release of ESB Guidance  – http://www.codeplex.com/esb

By Marty Wasznicky
Field Program Manager, Connected Systems Division

In October of 2006, we announced the preview of the Microsoft ESB Guidance at Microsoft SOA Conference in Redmond. This consisted of the following which enabled Microsoft partners and customers to build large and small-scale ESB solutions:


       Sample code built on BizTalk Server 2006

       Architectural guidance, patterns and practices

       Reusable BizTalk Server ESB and .NET components:

       Dynamic Transformation Service

       Dynamic End Point/Configuration Service

       Itinerary based Routing & Service Invocation

       ESB Portal

       Exception Management framework

       Namespace Resolution Service

       JMS (Java Message Service) pipeline component (IBM JMS over WMQ) 


Since that time we’ve achieved significant momentum:


       Several hundred requests for the ESB Guidance

       Several dozen customers incorporating the guidance into their projects

       Dedicated Microsoft ESB web site: http://www.microsoft.com/biztalk/solutions/soa/esb.mspx

       Dedicated Partner site for delivering the ESB Guidance: http://www.microsoft.com/biztalk/solutions/soa/esbpartners.mspx

       Press on the ESB Guidance from the SOA conference





       http://www.pcwelt.de/mobile/pda/news20061005/582163/ (German)

       http://www.programmazione.it/index.php?entity=eitem&idItem=34953 (Italian)


Due to the overwhelming demand and popularity of the ESB Guidance, we (the Connected Systems Division) and the Patterns and Practices group have agreed to jointly develop the ESB Guidance moving forward. 


As a result of the iteration of this partnership, we’ve released a new June Community Release build of the ESB Guidance on the new ESB Guidance community site, where all future iterations will be released here until our final release in October later this year. 


Although this June Community Release focused on bug fixes and refactoring the ESB Guidance for BizTalk 2006 R2, future releases will incorporate many new and augmented features such as:


       UDDI publishing and richer resolution options


       Enhanced ESB Portal and Exception Mediation

       Request-Response support for on and off ramps

       WCF Adapter integration

       New Samples and Guidance

       Third party SOA Management and Governance integration:

       Amberpoint Integration

       SOA Software Integration


Through our partnership with Patterns and Practices, we hope to raise the bar of quality and build an extended community to support our customers as they move forward with the ESB Guidance.


With the Patterns and Practices partnership, we incur the benefit of having Don Smith (Product Manager for Patterns & Practices – don.smith@microsoft.com ) take an active role in owning the ESB Guidance Community.  I will be coordinating feature development and community release schedules with Don, ensuring community feedback is incorporated into the ESB Guidance.


Please download the latest Community Release and provide us feedback.  We will be monitoring the discussion forums on the site. 


A more thorough description of the June Community Release can be found below.





About the June 2007 Community Release

This release focuses on refactoring the CTP build to accommodate the augmentation of existing features, as well as the addition of new features to be included within the final release targeted for October 2007.

Some of the changes for this release are:

%u00b7         The project namespace changes from Microsoft.BizTalk.ESB to Microsoft.Practices.ESB

%u00b7         All schemas follow W3C schema conventions for namespace, such as http://schemas.microsoft.biztalk.practices.esb.com/jms/system-properties

%u00b7         Installation scripts and instructions for manual installation are provided

%u00b7         All samples now install into the GlobalBank.ESB BizTalk application instead of their own individual applications

%u00b7         The following components have been rebuilt to work with the BizTalk Server 2006 R2 Beta 2 and Release Candidate builds:

%u25e6       JMS Pipeline Component

%u25e6       Namespace Pipeline Component

%u25e6       Exception Management API, InfoPath form and Pipeline component

%u25e6       Transformation Service, Helper and Agent

%u25e6       JMS Samples

%u25e6       Exception Management Samples

%u25e6       Namespace Samples

%u00b7         This release contains several updates to integrate with .NET version 3.0:

%u25e6       The Transformation Service is exposed as both an ASMX and a WCF service

%u25e6       The Exception Management Fault Service is exposed as both an ASMX and a WCF service

%u25e6       The UDDI helper class now uses native WCF calls and the features of .NET version 3.0. There is no longer a dependency on the Microsoft UDDI service (Microsoft.Uddi.dll)

%u00b7         There are a number of fixes for components and services included in this release. For more details, see:

%u25e6       Fixes for the Exception Management API

%u25e6       Fixes for the Transformation Service

%u25e6       Fixes for the JMS Component

%u25e6       Fixes for the Namespace Component

%u25e6       Fixes for the SetContext Component


Note: Although all other components in this release will compile and work with BizTalk Server R2, they still require some re-work. In addition, the ESB Exception Portal does not change in this release, and therefore the Exception Management Framework has not been tested with the older portal. The next community release will contain a prototype of the new portal.

Fixes for the Exception Management API

%u00b7         The Exception Management API now supports exceptions that occur in child orchestrations executed using the CALL shape. For example:

%u25e6       Orchestration A calls Orchestration B

%u25e6       Orchestration B contains exception handling code that invokes the CreateFaultMessage method and assigns a fault message

%u25e6       An exception occurs in Orchestration B and the ESB Exception Framework should publish the message

%u25e6       The execution path no longer fails and causes an error within the CreateFaultMessage method

%u00b7         InfoPath form rendering exceptions from the ESB Fault Processor pipeline no longer cause an error when scrolling through context properties

%u00b7         The ESB processor pipeline now includes whitespace support in the reader

%u00b7         The properties for the fault schema change in this release. There is no promotion of FaultDescription, and the description now accepts more than 255 characters

%u00b7         Extension of the existing property schema supports additional internal error information

%u00b7         The schema namespace changes, and the InfoPath template has been renamed

%u00b7         Class references replace the string references for the context property name and namespace used when accessing context properties

%u00b7         This release supports MIME-type detection for the body of a message

%u00b7         Failed Message Routing scenarios now support flat files and binaries

%u00b7         Streaming is implemented for large files

%u00b7         Correct identification of the send port now occurs in one way messaging scenarios

%u00b7         There is support for two-way messaging scenarios, such as the typical SOAP request-response cycle

%u00b7         All project versions are now

%u00b7         The native BTS stream libraries replace all custom streaming classes

%u00b7         A new ContextProperties class allows pipeline components to access property information

%u00b7         The orchestration time stamp in now expressed in UTC

%u00b7         A new WCF-based Web Service exposes fault information

%u00b7         All references to http://org.kp.esb.engine and the “bootcamp” namespaces in InfoPath schemas are removed

%u00b7         New scripts update the Resources folder in the BizTalk Server application, and generate an MSI based on the resource artifact files

%u00b7         Minor modifications to the code catch more exceptions, in particular by checking for null references

%u00b7         The component detects non-HTML and non-text content, and encodes these as base-64 strings

%u00b7         The reporting schema and InfoPath template now contain a MIME-type property

%u00b7         There is support for rendering the content of XML CDATA sections

%u00b7         The schema type for the content block within the reporting template changes from Any to CDATA


Fixes for the Transformation Service

%u00b7         The Transformation Service now throws a null exception if the mapName parameter is null.

%u00b7         The Transformation Service now has no dependency on the Microsoft UDDI service (Microsoft.Uddi.dll).


Fixes for the JMS Component

%u00b7         The strong name key file binding now occurs during the linking phase so that the Manifest phase does not invalidate the signature of the assemblies.

%u00b7         The component now uses the Microsoft.Practices.ESB.snk key file included with the source.

%u00b7         The JMS Sample uses a new Queue Manager name, and only four queues.


Fixes for the Namespace Component

%u00b7         The NamespaceException now inherits from ApplicationException, which corrects the issue where exceptions appear in the Event Log as “Reason: Unknown”

%u00b7         Corrections to processing of the ExtractionXPath property solve previous extraction issues

%u00b7         A new validation routine introduced prior to pipeline processing ensures that required properties are set at runtime

%u00b7         Regular expressions now check that separator property value is valid (or is empty), that namespaces are not in the reserved range (ns0 to ns6), and that the specified namespace prefix is alphanumeric

%u00b7         The component now checks that either the XPath or NamespaceBase property is set

%u00b7         The component now compares the existing and the new namespaces, and just returns the original message to the pipeline if they are the same

%u00b7         The component no longer raises an exception if the XPaths property is null, which allow the use of a static namespace if required

%u00b7         Various string comparisons carried out within the component have been corrected


Fixes for the SetContext Component

%u00b7         The component uses an updated namespaces for property schemas

%u00b7         The component now exposes EndpointUddiServer and MapUddiServer properties

%u00b7         The component now contains logic that ensures the value of a SOAP header is not overwritten by a property value provided in the pipeline instance rather than in the SOAP header

%u00b7         There are several new trace statements that output the resolved endpoint



Marty Wasznicky
Regional Program Manager – BizTalk Server
Connected Systems Division
Microsoft Corporation

MCSE, MCSD, MCDBA, CNE, MCTS in BizTalk 2004


333 S. Grand Ave., Suite 3300, Los Angeles, CA 90071

%u00c9213.806.7484%u00c8310.980.5495 %u009amartin.wasznicky@microsoft.com

BizTalk Server Webcasts:


BizTalk Server 2006 Virtual Labs:


BizTalk Server 2006 Trial Download:


BizTalk Server 2006 Home Page:




A Test suite for business rules

A Test suite for business rules

I mentioned in a previous posts that the rule validation in the interactive rule map (cause-effect graph between terms and rules) is part one of the rule validation.

In the image on the right (click to zoom) you see the second part that is currently being developed. Test cases that are created in the interactive rule map can be saved to a test suite. A test suite (a collection of test cases for business rules) can be executed in a batch process.

For every test record we compare the user defined expected value with the rules engine computed value. Any discrepancies are flagged with a red info, and the test record would be marked red to indicate a failure. Green test records have all computed values equal to the business users defined expected values.

In the output terms you have to indicate which term you want to set as a goal for the rules engine. One test suite can process multiple goals. But every test record can only have one goal defined.

Similar to the meta information on a business rule, a test record contains the meta information of who the author is, when it was created, a description field etc.

You can imagine that among business users a difference of opinion might exists what the expected outcome value must be for a particular situation. We can not say what is right or wrong withing a rule policy, but we can show there is a difference.

Finally, the test suite can be used perfectly for regression testing your rule policy and can give a good impact analysis what happens when you modify your rule policy.

Posted by Picasa

Microsoft Enterprise Service Bus Guidance – Intro

Wow……I can’t even remember the last time I blogged.   I’ve been living on an airplane; it seems like for years now.  I guess an update is in order.  I’m still working for Microsoft….in the Connected Systems Division.  That’s the place in Redmond where we build things like BizTalk, Host Integration Server and WCF.  I still cover the West Region for Microsoft in Regards to BizTalk….as well as a bit of the Northeast Region.  I still run the BizTalk Virtual TS program….a program I designed in SoCal back in 2004….but I’ve been able grow it across the nation where it now contributes to almost a third of the US BizTalk business.  We’ve even got seeds of it growing in Canada and EMEA…pretty cool.

Most recently though I’ve been heads down on building the Microsoft ESB Guidance for BizTalk….a project I started about a year ago from the work that Lukas Cudrigh (Microsoft NorCal), Brian Loesgen (Neudesic) and I started at a major healthcare company (Kaiser).  You can read all about it on Brian’s blog (http://geekswithblogs.net/bloesgen/archive/2006/11/03/96062.aspx).

We released the first build of this last October at our Microsoft Redmond SOA event.  As you can imagine….it took off like wild fire!  We set up a Microsoft email alias for those interested in it.  I got inundated with several hundred requests for it in a matter of months!

Short story, we were able to convince the powers that be that this was the way to go.  I got the green light to move forward and we are now partnering with the Patterns and Practices team to revise and complete the Guidance to work BizTalk Server 2006 R2 (which we expect to release in September).  The Guidance itself, we expect to ship shortly after R2, probably at the beginning of October this year.  The ESB Guidance will be an official branded release by the Patterns and Practices team. 

On the Patterns and Practices side, Don, Dmitri, Rajat, Alex and the team are keeping us honest and the quality bar high (I think Rajat spent his entire weekend just testing our latest drop).  On the development side, I’m the architect and development lead for a small pack of Partner based resources (Sogeti, Magenic, CTS and Neudesic).  We’re a small but passionate group and, together, I think we’re going to deliver one of heck of a package to the community.

As we continue to develop the features and dream of new things on the horizon, I’ll try to keep my ideas posted here.  In the meanwhile, I’ve posted below the  latest email I sent to the community at large regarding our latest CTP release of the ESB Guidance on codeplex (www.codeplex.com/esb ).  If you’re interested, you can also peruse through the current documentation on Alex’s site, http://www.daveandal.net/articles/esbdocs/



Hosting workflows in BizTalk

Hosting workflows in BizTalk

I’ve been pretty quiet lately – mostly because I’ve been working on this project
for hosting workflows inside of BizTalk 24×7 (well more like 16×7  – I’m too
old to do 24×7 anymore even with RedBull).  Its been really fun getting this
code to work (generating orchestrations from workflows).

Feel free you can feel free to contact me if you have question and look for more posts
about this sample and how it works.

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
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 around where you set it. As far as
I can see, it doesn’t make much sense to use it unless the receive activity is the
entry point of your workflow, but currently nothing prevents you from setting it if
is not. That said, I guess it might be difficult to validate this correctly given
the WF execution model.

Continuing Workflows

The Receive Activity doesn’t limit you to starting new workflow instances; it also
allows your workflow instance to wait until a message is received (through a service
invocation from a consumer) to continue execution. This is a key scenario for long-running
processes because the workflow will have all the necessary context within the business
process to interpret the coming message correctly and act on it.

How does the host know which workflow instance should process a given message, then?
The answer lies in the binding context. WF requires the consumer of the service to
send a token alongside the request message that tells it what workflow instance the
message is for. This token is, essentially, the WorkflowInstanceId, and can be sent
either as an HTTP Header or as a SOAP Header.

Using the WorkflowInstanceId as the instance selection token is a logical choice for
WF, as the Workflow Runtime, as well as the persistence service, already have clear
knowledge of what the ID means and how to use it, so getting the right workflow instance
to pass the message to is basically just a call to the GetWorkflow() method of the
WorkflowRuntime object.

For this entire process to work, both the server and the client must use the special
WSHttpBindingContext class, which helps makes this process a bit more transparent
(particularly for the workflow service). On the client side, naturally, the service
consumer must be, somehow, aware of the correct workflow instance ID to use as the
token. Sometimes, this will be handled in a very transparent way by the infrastructure,
but sometimes you’ll need to make it more explicit. And by the way, the WSHttpBindingContext
class is also used for WCF Durable Services.

Serge Luca has an extensive
of using WF Services in several scenarios that is pretty interesting to
check out.

The Limitation of IDs

This entire mechanism works fine for WF Services. However, after I saw this the first
time, there was something that I didn’t quite like about it, and it kept nagging in
my head. A few days ago I finally realized what it was: As a first option for having
this feature, it is pretty useful, but it is, in a way, a significant step back.

The problem with using the WorkflowInstanceId as the linking element between the service
consumer and the workflow implementing the service is that it has, essentially, no
business meaning. While it is a very useful technical discriminating ID, most business
scenarios where this kind of long running services and processes are involved already
have natural correlating identifiers
in the problem domain, like a purchase order
id, a loan id, or a combination of customer id and tracking id.

There are several implications of this simple fact:

  • Consumers of the service become aware of the fact that there’s a workflow on
    the other end of the service. This is actually merely an implementation detail of
    the service which should be transparent to the consumer as much as possible.
  • Consumers might now be forced to track yet another id, and one that has no business
    meaning at all. So instead of just having, say, the order id around they also need
    to find where to store the workflow id.
  • The WorkflowInstanceId becomes an added part of the service messaging, but it is one
    you might not always be aware of because it doesn’t make part of the core messaging

Of all of this, I think the second one is what bothers me the most. If you’re ever
used the wonderful Correlation Set mechanism introduced in BizTalk 2004, then you’ll
definitely see where I’m coming from, as this is a bit more restrictive and less expressive
than what we can do right now with BizTalk. In fact, this is more akin to the limited
correlation mechanism we had back in BizTalk
(though that required jumping through a lot more hoops).


All in all, this seems like a very welcome addition to both WCF and WF, even though
there are limitations in this first release. I’ll be watching closely how both develop
as they take a bit more of the core messaging and orchestration strengths that Biztalk
has enjoyed for the past few years.

The day has come – BizTalk Orchestration Wrapper for WF!!

Finally it’s here – there was some talk internally within MS about an adapter being
built to communicate to WF Runtime, thus allowing hosting of WF workflows within BizTalk.

At the moment we’re at cross roads with BizTalk 2006, as the Orchestration/Business
Process designers and technologies is built on a language called XLANG which is compiled
into C# and executed.

On the other side, we have WF workflows, XAML, XML, .NET based, extensible and looking
good…..but it needs to find a home. It’s homeless but always keen to meet up with
a host. The question of hosting WF Workflows is not taken lightly as scalability,
availability, durability etc all come into the equation (the ‘hello world’ WF console
application just doesnt cut it 🙂 )

So let’s get the best of both worlds – I previously did a MSDN
webcast on this around the time when the message from MS was “for small stuff
– use WF. For bigger things use BTS” – but why cant the 2 worlds live together?

Now – they can!!!!

Microsoft WF Team have released ‘BTS Extension for WF’ where there is ‘no
BizTalk code required’
(hmmm….maybe I should stop my mission of finding
BizTalk people and look at WF people).

Go and register on the connect site/fill in a quick survey and get downloading!!!!

Grab the BTS
Extensions for WF here


Happy playing……..it’s wabbit season…no duck season….no wabbit season….