Yesterday, QuickLearn released their training schedule for the remainder of 2010.

Due to increased demand, QuickLearn doubled their BizTalk Server 2009 course offerings including the new dates for the BizTalk Expert Series for ESB Toolkit 2.0. 

Check out the calendar to see all upcoming classes!

After spending hours learning to play the fake guitar simply to get a higher score, I often wondered why someone couldn’t make a game to learn useful skills. Where’s arithmetic Hero? Going-to-bed-on-time Hero? Microsoft Office Ribbon Hero?

Well, at least the last one finally exists. Microsoft Ribbon Hero lets you learn to use the Microsoft Ribbon and earn points while doing it. They even have Facebook integration so you can compete against your friends and coworkers. (My FB account is here, if you want to challenge me)

The premise of the Ribbon is based on sound UI design (it’s even won awards), but it’s so different than what we were used to. If you’re like me, you’ve figured out where your most commonly used items are on the Ribbon, but haven’t fully explored the other features and often have to hunt for that one option that you use so rarely. Well, let’s take that need for points and apply it to learning something we can actually use in everyday life.

Finally, a game you can play in front of the boss. After all, you’re increasing productivity!

The .NET Endpoint blog announced this morning the availability of Windows Server AppFabric Beta 2, which can be downloaded at http://msdn.microsoft.com/appfabric. According to the announcement, Beta 2 was written to work against the RC of Visual Studio 2010, and is apparently now feature complete:

This build represents our “feature complete” milestone. That is, it contains all the features that we plan to ship in Windows Server AppFabric v1 by Q3 of 2010. For this release we focused on building a provider model for persistence, monitoring, and cache configuration stores. In our Beta 1 release we supported only the SQL Server based persistence and monitoring providers that we shipped and supported only an XML file based or SQL Server based cache configuration store. In Beta 2 we now also support providers for other database platforms or for other types of stores, in the case of persistence and cache configuration.

This is an exciting milestone for the team, and will certainly be a great time to begin evaluating Windows Server AppFabric for inclusion in upcoming projects.

While browsing Microsoft's Virtualization site, I stumbled across an upcoming event:

Looking at Desktop Virtualization including VDI? Thinking about Windows 7 migration; Want savings, but wondering about ROI?

Join Microsoft, industry experts and IT leaders: Desktop Virtualization Hour, March 18th, 9am PST.

This is all the information they’re sharing with the public at the moment, which normally might indicate a lack of planned content… but considering the fact that they purchased a domain just for this event, http://www.desktopvirtualizationhour.com/, Microsoft is being suspiciously vague about their plans.

I managed to find a ZDNet whitepaper posting from January that has some extra lines of description:

Have more questions than answers on the topic?
...
Watch and interact live with Microsoft, industry experts and IT leaders for a moderated televised discussion. Submit your questions in the hour or in advance.

Does the fact that these lines don’t appear on the event-specific domain mean something? Perhaps they’ve already chosen the questions they’re going to answer, or perhaps the list of experts grew too large to allow viewer participation? We’ll have to wait and see what transpires.

In the mean time, you can study up on VDI in preparation of this event:

• Microsoft's Virtualized Desktop Products and Technology – Homepage for Microsoft’s VDI solutions
• TechNet video series on VDI deployment (Part 2, Part 3) – Matt McSpirit walks through setting up VDI

Last week I undertook a completely unscientific study of the .NET Blogosphere (as much as I loathe that term), to determine which namespaces and classes people are most excited about, confused by, or frustrated with – at least to the point that they would dedicate the time to write in their blog about them. My methods for undertaking this study were rather simplistic. I wrote a quick and dirty console application to reflect through the .NET Framework namespaces and classes, and search the internet for mentions of them alongside the terms .NET and blog. For classes whose namespaces contained no periods, the full name of the class was used as the search term. For those classes whose namespaces did contain periods, the namespace and name of the class were used as separate search terms. For example, the class System.IO.File would result in a search for “System.IO File .NET blog”, whereas the class System.String would result in a search for “System.String .NET blog”.

More than to just do a popularity contest of the different classes, I wanted to try to determine the best sources of information for each component of the framework. I wanted to see which sites seemed to consistently beat out others as authoritative sources with complete coverage of a given area. In preparation for the transition to .NET 4, I also was interested to see if the features new to .NET 3, and .NET 3.5 received similar coverage to those classes/namespaces that are used in nearly every project created. This final concern will require further testing and analysis before any conclusions can be reached.

What I did find, however, was that (perhaps unsurprisingly considering the methods) those classes/namespaces which one might use more often round out the top 10 result getters:

I was surprised at how strong of a showing the Microsoft.VisualBasic namespace had among all other contenders. Another interesting study would be to look into those sites that are represented in the result count and find the ratio of C# to VB code contained within.

When looking only at classes, we find the following in the top 10:

From here it looks like features from .NET 2.0 (List<T>) and .NET 3.0 (System.Windows.Window) have gotten enough traction to make a big splash. Generics have had quite a long time to catch on so that’s not surprising. Features from WPF making the top 10 already is surprising (considering how much longer classes have had to be written about), and in this case may simply come as a result of the search term that the application used, which would split off Window from System.Windows.Window as its own term alongside the rest.

The top 10 sources for information about .NET would appear to be the following:

The number next to the name of the site indicates how many classes/namespaces for which the site is the top result. Further investigation shows that this might be inaccurate since dotnet247 seems to just index the entire framework and aggregate information from other sites in an automated fashion. Sounds like a great way to make some money from ads, but it might not be the best information source (though is still fairly genius). MSDN blogs definitely provide some serious coverage of the .NET Framework, and likely have excellent information about those classes/namespaces for which they were the top results.

Another interesting statistic that came out of this entirely informal study is that 29% of the .NET Framework (3.5) has less than 5 articles of coverage on the internet. In fact there are 389 classes or namespaces that would appear to have nothing written about them at all (according to the semi-flawed methodology described above).

You can use the download link below to download the complete results that contain all of the raw data that was analyzed, as well a pivot table, and some charts that can be used to explore it to some extent. What interesting information can you find? Has anyone else done a more formal survey of the same?

I was looking over some of the industry news this morning, and spotted this gem from Miguel de Icaza’s blog:

We are also porting our C# compiler to work with Microsoft's Reflection.Emit to enable us to run our C# Interactive Shell in Silverlight applications and to allow .NET developers to embed our compiler in their applications to support C# Eval.

For those that typically shy away from penguins: Miguel is heavily involved in the Mono project. Mono is a project under the wing of Novell to create an EMCA-334/335 compliant implementation of C# and the CLI. The project includes much of the base class library found in the .NET framework, and also includes more project specific classes. The big selling points for me are binary compatibility with existing .NET assemblies, and availability on multiple platforms.

This is certainly exciting technology (just look at the reaction Anders received demoing very similar functionality at PDC2008). Now imagine that same type of experience in the browser (minus the Windows Form popping up out of no where, since no one likes pop-ups anyway). Imagine games that can be scripted in-play, or instantly extensible rich client applications.

Naturally there will be security considerations, and testing considerations, but for now it is what it is: fairly awesome.

Visit the new QuickLearn Community Portal to get breaking news and access our free learning resources for BizTalk, SharePoint, .NET 4.0, and Microsoft Virtualization!

Join the community portal to:

• Connect with QuickLearn instructors and your peers.
• Subscribe to the newly redesigned QuickLearn Team Blog to find enlightening blog articles from our team of technologists. 
• Explore the brand-new QuickLearn Technical Library which contains a compilation of technical articles, useful links, and other relevant content to jumpstart your knowledge or dill-down on emerging technologies.
• View Screencasts created by QuickLearn Technologists to highlight their favorite features of emerging Microsoft Technologies.

Happy Browsing!

I was lurking around the ESB Toolkit forums yesterday, and got involved in an exchange with someone who was hitting the same roadblock to the Itinerary Designer that a lot of people hit: confusion with the model elements and extenders. Upon my first exposure to the Itinerary Designer it took me a week to get over the learning curve of this, and to understand why every send operation seemingly involved two off-ramp shapes instead of one.

Now in the case of that thread, the problem was actually not having a properly formatted SOAP request for the service that was going to be invoked (also a fairly common issue), but getting to the actual issue took cutting through some of the confusing bits of how the itinerary services themselves are implemented, and what they do.

That being said, I took some time last night to write up an article on the different model elements in the itinerary designer, their extenders, and how they can be used to compose an itinerary. You can access the article here: Making Sense of Model Elements and Extenders in the Itinerary Designer

Side note: The article is now part of the brand new (and still under-construction) QuickLearn Technical Library, which will soon contain many more similar articles and links to technical resources for all of the technologies about which QuickLearn teaches.

That’s all for now!

I was lurking around the ESB Toolkit forums yesterday, and got involved in an exchange with someone who was hitting the same roadblock to the Itinerary Designer that a lot of people hit: confusion with the model elements and extenders. Upon my first exposure to the Itinerary Designer it took me a week to get over the learning curve of this, and to understand why every send operation seemingly involved two off-ramp shapes instead of one.

Now in the case of that thread, the problem was actually not having a properly formatted SOAP request for the service that was going to be invoked (also a fairly common issue), but getting to the actual issue took cutting through some of the confusing bits of how the itinerary services themselves are implemented, and what they do.

That being said, I took some time last night to write up an article on the different model elements in the itinerary designer, their extenders, and how they can be used to compose an itinerary. You can access the article here: Making Sense of Model Elements and Extenders in the Itinerary Designer

Side note: The article is now part of the brand new (and still under-construction) QuickLearn Technical Library, which will soon contain many more similar articles and links to technical resources for all of the technologies about which QuickLearn teaches.

That’s all for now!

Imagine that you have written an application that will need to invoke a service at some point. You can hard code the service address, you could place it in configuration, you can stick it into an external registry (a la UDDI), or you could come up with some custom method for resolution (e.g., storing endpoint information in a table of a SQL database).

However, Juval Lowy reminds us that we don’t have to re-invent the wheel. He wrote an excellent article in last month’s MSDN magazine about simple discovery in WCF. In the article he provides a simple explanation of what it is, and how it works, and even provides sample classes that can jump-start your development.

You can check out the article here: Foundations - Discover a New WCF with Discovery

Just before the long weekend, Microsoft quietly released a documentation update alongside their RC release of Visual Studio 2010. If you were dying to know how to implement Out-of-Order Message Processing in Workflow Services, click-away because you shouldn't find any more place holder content where you're expecting technical articles.

This should definitely lessen the learning curve a bit more.

Check out the announcement via The .NET Endpoint blog here: The .NET Endpoint: RC docs are live!

I was on the MSDN Forums for the ESB Toolkit this morning, and came across a question from fellow BizTalk developer Barry Woods. He was asking about routing decisions in itineraries, so I threw in my two cents on the topic. Then I stepped back for a second and realized that there is a fantastic feature of the ESB Toolkit 2.0 that no one talks about.

This enigmatic feature stealthily crept into the Toolbox in Visual Studio, when you weren't looking. It takes up two slots in the toolbox, because two are necessary to compose its awesomeness. I'm referring to the "Itinerary Broker Service" and the "Itinerary Broker Outport"; together they make up the feature that is the Broker Service. So what does it even do, and why do I need it? Well to get to that, first we need to take a step back and talk about how version 1.0 of the ESB Guidance handled itineraries, and how version 2.0 handles them. If you would rather not hear that discussion, click here to skip the fluff.

In version 1.0 if the ESB Guidance, itineraries, represented as xml, were read as a sequential list of steps that needed to be executed. These steps were numbered sequentially just like items in an array. The Itinerary designer can serialize your model into this format, and will do so when you set the Export Mode of your itinerary model to Default.

However, if you switch this Export Mode to Strict, you will notice a few things change in the XML output. I would recommend you keep this XML output up in a separate tab as you're reading through the next section.

First of all, each messaging-based step (termed an Itinerary Service in ESB Toolkit lingo) has a stage attribute defined that correlates to the Container property of the model element in the designer.

Every step also has a businessName attribute associated with it which corresponds to the Name property of the model element in the designer. This name will be used in BAM tracking of itinerary execution.

Next you will notice that itinerary services can now have a PropertyBag associated with them that can be configured at design time for a different experience in each itinerary. This also means that you do not have to create a custom resolver each time you have an orchestration service that needs some business specific metadata that isn't related to what resolvers can already return.

Finally you will notice that each step has an id attribute, and a nextId attribute (with one exception that we will note later). This means that the services are no longer executed in a positional/sequential fashion, but instead are represented as a linked list that can be modified at runtime.

Thus, we are brought back to the Itinerary Broker Service. This is the only service that allows us to select the next link in the chain, and thus change the entire path of execution that the itinerary takes. Right now the Itinerary Broker Service is only available within the pipeline, though designer support has already been built for you if you decide to create a custom orchestration-based broker service.

With minimal effort you will be able to have an itinerary that looks like this.

In order to begin using the Itinerary Broker Service, go ahead drag one on to your design surface, and then give it a unique name. Since this can only execute within the pipeline, you are either going to have an On-Ramp shape that connects into it, an Off-Ramp shape that connects into it (on the receive side of a two-way off-ramp), or another messaging service shape that connects into it. Make whatever connection makes sense for your scenario.

Now you will need to decide how many possible paths there will be through your itinerary. You don't have to account for every path a message will take to its destination, but rather which steps it will take to get there. For example, if you have two instances in which a message will have to be transformed once and then routed, that can be taken care of with a single path that includes a transform step and a routing step with a more dynamic resolver (e.g., the BRE resolver). If you have then another instance in which a message would have to be transformed twice before being routed, this would constitute another path through your itinerary. Once you decide how many paths you will need, drag an Itinerary Broker Outport on top of the Itinerary Broker Service you just added.

This will create smaller model elements that can be used to attach to other services. Which means that these allow this element to branch out just like you might have a decide shape branch in a BizTalk Orchestration. Go ahead and set the Name property on these to describe the path through your itinerary to which they will connect.

Next you will want to add a Resolver to the broker service, just like you would with any other Itinerary Service. In this case you will want to set the Resolver Implementation property to CONTEXT. This will return the context of the message being processed formatted like this. That's another tab you will want to keep open as we continue this discussion.

Normally resolvers are used for runtime resolution of endpoints, or transformations. Each resolver is given a configuration string, and returns a dictionary of key/value pairs as the result of its execution. Itinerary Services can then use the information in whichever way they please. In this case the Broker Service will use the very first key in the resolver dictionary (whatever it may be) as a value to switch on.

Put on your C# hat for a second and consider the following code:

Now this is a silly example, but here we see that we are making a routing decision based on the value of item. The string named item in this example corresponds to the role of the Resolver in the broker service. The next thing we need to add is our cases. This corresponds to the Filters. So, go ahead and add a filter for each path you would like to take.

Name these filters according to the path that they will follow, or the condition on which they will be filtering. Next set the Filter Implementation property to XPATH. XPATH is the only filter that comes with the toolkit. Notice the Expression property of the filter. This expression will be evaluated against the first item returned by the resolver. In the case of the CONTEXT resolver, it will be this (which you should have open on another tab). So we could configure an expression that considers the inbound transport type for example:

//Property[@name='InboundTransportType']='FILE'

This will evaluate true for all messages that sent through a receive location with a file adapter. For those of you out there looking to build an orchestration-based broker service, filters will be serialized as properties in the property bag for the broker service itinerary step.

After you have configured your filters, you will have to return to your outports to configure which Resolver and Filter they are comparing by selecting them in the Filter and Resolver properties of the outport. Now there is a possibility, depending on the expressions you use, for two outports to be associated with a filter that will return true. In this case you can set the Order property of the outports to determine which one has precedence.

At this point, you will simply need to wire up your broker service outports to the proper services that should follow, and you will be good to go.

I have created a super simple sample itinerary that will switch based on the transport type, and route the message to a different location. You can find that sample here. Also be sure to check out our BizTalk screencasts and ESB screencasts.

The end for now.

Microsoft BizTalk ESB Toolkit 2.0 released to web yesterday evening, and if you have not been following the earlier CTPs, now is a great time to get on board. The name has been changed, a support model has been introduced, and official MSDN forums for the Toolkit have been made available.

Since there are not any VMs that you can simply download and get up and running with quickly, I decided to put together a quick and dirty installation guide for installing the Toolkit on a single server in a 32-bit virtualized environment for evaluation purposes. What follows are the steps to get you from 0 to ESB with all of the sample applications.

1. Install the Pre-Requisite Components
   • Microsoft Windows Server 2008 or Windows Server 2003 (except Web Editions) operating system
   • Internet Information Services (IIS) 7.0 with IIS 6.0 extensions or IIS 6.0 (used for Web services and the ESB Management Portal)
   • Microsoft SQL Server 2008 or Microsoft SQL Server 2005
   • Microsoft BizTalk Server 2009 Enterprise Edition, including Business Activity Monitoring (BAM)
   • Microsoft Visual Studio 2008 SP1 (required on development computers)
   • Microsoft UDDI Services 3 (required by UDDI resolver and dependent samples)
   • .NET Framework 3.5 SP1
   • Microsoft Chart Controls for Microsoft .NET Framework 3.5
   • Enterprise Library 4.1
   • Microsoft Visual Studio 2008 Software Development Kit (SDK) 1.1 (required by the Itinerary Designer when installing from source code) [optional]
2. Install the main MSIs (Docs/Toolkit x86)
   • Currently available for download here.
3. Import/Install C:\Program Files\Microsoft BizTalk ESB Toolkit 2.0\Microsoft.Practices.ESB.ExceptionHandling.msi
4. Import/Install C:\Program Files\Microsoft BizTalk ESB Toolkit 2.0\Microsoft.Practices.ESB.CORE.msi
5. Give SQL Service account permissions to all of the BAM related databases
6. Using the bm.exe tool, deploy the BAM Activities located at C:\Program Files\Microsoft BizTalk ESB Toolkit 2.0\Bam
   • bm deploy-all -DefinitionFile:"C:\Program Files\Microsoft BizTalk ESB Toolkit 2.0\Bam\Microsoft.BizTalk.ESB.BAM.Exceptions.xml"
   • bm deploy-all -DefinitionFile:"C:\Program Files\Microsoft BizTalk ESB Toolkit 2.0\Bam\Microsoft.BizTalk.ESB.BAM.Itinerary.xml"
7. Run C:\Program Files\Microsoft BizTalk ESB Toolkit 2.0\Bin\ESBConfigurationTool.exe
   • You have to apply settings on each page before continuing to the next page
8. Run C:\Program Files\Microsoft BizTalk ESB Toolkit 2.0\Bin\Microsoft.Practices.ESB.UDDIPublisher.exe
   • If errors, uncheck Require SSL setting in UDDI3 MMC
9. Extract C:\Program Files\Microsoft BizTalk ESB Toolkit 2.0\ESBSource.zip to C:\Projects\Microsoft.Practices.ESB\
10. Create snk at C:\Projects\Microsoft.Practices.ESB\Keys\ [command below requires Visual Studio Command Prompt]
    • sn -k Microsoft.Practices.ESB.snk
11. Mark C:\Projects\Microsoft.Practices.ESB\ as NOT read-only
12. Run the command below
    • powershell Set-ExecutionPolicy unrestricted
13. Run the command below
    • C:\Projects\Microsoft.Practices.ESB\Source\Samples\DynamicResolution\Install\Scripts\Setup_bin.cmd
14. Run the command below
    • C:\Projects\Microsoft.Practices.ESB\Source\Samples\Itinerary\Install\Scripts\Setup_bin.cmd
15. Run the command below
    • C:\Projects\Microsoft.Practices.ESB\Source\Samples\MultipleWebServices\Install\Scripts\Setup_bin.cmd
16. Repeat for remaining samples (setup_bin.cmd or SampleName_Install.cmd for each)
17. Open the Visual Studio solution named ESB.Portal.sln from the C:\Projects\Microsoft.Practices.ESB\Source\Samples\Management Portal\ESB.Portal folder, and then make sure that the section of the Web.config file contains the correct connection strings for the ESBAdmin database.
18. EDIT: In same solution, open the ExceptionService's web.config file, and update the connection string.
19. Open C:\Projects\Microsoft.Practices.ESB\Source\Samples\Management Portal\ESB.AlertService\ESB.AlertService.sln, and change TargetPlatform property of the Setup project to x86.
20. Build C:\Projects\Microsoft.Practices.ESB\Source\Samples\Management Portal\ESB.AlertService\ESB.AlertService.sln
21. Build C:\Projects\Microsoft.Practices.ESB\Source\Samples\Management Portal\ESB.UDDI.PublisherService\ESB.UDDI.PublisherService.sln
22. Run C:\Projects\Microsoft.Practices.ESB\Source\Samples\Management Portal\ESB.AlertService.Install\Debug\setup.exe
23. Run C:\Projects\Microsoft.Practices.ESB\Source\Samples\Management Portal\ESB.UDDI.PublisherService.Install\Debug\setup.exe
24. Use the My Settings page in the portal to configure the main portal settings
    • Default URL: http://localhost/ESB.Portal/PortalSettings.aspx
25. Configure the settings on the Fault Settings page in the portal
    • Default URL: http://localhost/ESB.Portal/Admin/Configuration.aspx
26. Configure the settings on the Registry Settings page in the portal
    • Default URL: http://localhost/ESB.Portal/Uddi/UDDIAdmin.aspx

Once you have the BizTalk ESB Toolkit 2.0 installed, I would recommend you read the following documents (in order) in the official documentation to give you a tour of what all is there, and even get fairly deep into the inner-workings of the Toolkit, and extensibility opportunities:

1. Overview of the BizTalk ESB Toolkit
2. Architecture of the BizTalk ESB Toolkit
3. Itinerary-Based Routing
4. BizTalk ESB Toolkit Message Life Cycle
5. The ESB Management Portal and Fault Message Viewer
6. Prerequisites for the Development Activities
7. Development Activities
8. Running the Itinerary On-Ramp Sample
9. Installing and Running the Scatter-Gather Sample
10. Installing and Running the Multiple Web Services Sample
11. The ESB Itinerary Selector Component
12. The ESB Itinerary Forwarder Component
13. The ESB Dispatcher Component [Most of the magic of ESB happens here]
14. Implementing Design Patterns in Itineraries
15. Creating a Custom Itinerary Service

When you install ESB 2.0 guidance from the source (CTP Build 1), the ESB Configuration tool does not compile. This means that in order to configure the Databases and Web Services, you have to manually configure each of these sections by hand. When trying to compile the ESBConfigurationTool solution, the error you get is here:

The issue is that the DirectoryObjectPicker C# Class library project is referencing an Interop assembly named ActiveDs.dll. This assembly, in this build, does not have the correct signature. To circumvent this issue, one option is to try to refresh this interop assembly by re-referencing the Active DS Type Library as show here:

By doing this, an interop assembly is created using the .NET Framework SDK utility called TlbImp.exe. This process invokes the utility to create an interop assembly. However, this assembly that is created by the TlbImp utility is not signed by default.

You may be asking, "what does have to do with the DirectoryObjectPicker project?"

It just so happens that the DirectoryObjectPicker project needs to be signed and eventually installed into the GAC. Any project that needs to be signed and installed into the GAC has a constraint that says any referenced assemblies also need to be signed as well. We reach the real problem here. The original ActiveDs.dll is not signed correctly and the one created by re-referencing and using the Utility is not signed at all. There are ways in which we could just force a signature on an interop assembly, but we should not because we would be, in effect, “spoofing” the assembly. We should use the original manufacturer’s signature and use its interop version of the assembly.

Here’s the fix. Search your Root drive, and look for any file with the name ActiveDs. Chances are that you have installed other libraries or frameworks that use this fairly common assembly. It can be found inside the BizTalk Accelerators, WCF LOB adapter pack, and other .NET Frameworks. The one that worked for me is the Interop.ActiveDS.dll located inside the BizTalk RossettaNet Accelerators A4RN Msi folder:

Once you’ve found the right match, copy this assembly and place it into your DirectoryObjectPicker source folder. Add a reference to this assembly instead.

What you’ll notice at this point is that the project still doesn’t compile. The reason is because the namespaces are not quite correct. Compile the project and inside the source code file (NameTranslator.cs to be specific), where the few errors occur, add a using statement such as this:

Adding this line of code will create a Namespace alias that points to the correct namespaces. Compile the project and remove the delay signing on each of the two projects: (DirectoryObjectPicker, EsbConfigurationTool). Build and install the DirectoryObjectPicker project into the GAC, and run the EsbConfigurationTool. You’re done.

Happy ESB'ing!

It is no secret that Microsoft has been working on bringing its Enterprise offerings up to date, readying them for the next generation of applications and services, and fixing small pain points that have vexed developers for years. In just a short while, BizTalk Server 2006 R2 will make way for BizTalk Server 2009, and another interesting product from Microsoft will realize next version status. That product is Microsoft Enterprise Service Bus (ESB) Guidance 2.0.

What is an Enterprise Service Bus?

Dmitri Ossipov, a Senior Program Manager for Microsoft working on the ESB Guidance, in his interview on .NET Rocks defined ESB as an "architectural paradigm for policy driven mediation." Nicholas Allen, a Program Manager at Microsoft working on BizTalk Server, argues that "the clearest definition of what companies think ESB means comes from looking at the products that they build." In the case Microsoft's ESB offering we see a solid implementation of the Routing Slip pattern built on top of BizTalk Server sprinkled with ample extensibility points. In the world of the ESB Guidance Routing Slips are called Itineraries, and act like an order placed at a menu of services that is the bus. The ESB Guidance provides flexibility through a loosely coupled design that allows routing and transformation decisions to be made at runtime instead of having to be statically configured at design-time. This enables service composition, dynamic transformation, and adds support for scenarios previously unimaginable in a BizTalk Server environment.

Version 1.0 of the Guidance was a paradigm shift for many BizTalk and .NET developers, but version 2 has the potential to take it to the next level. It introduces some killer new features such as the Itinerary Designer that can reduce XML induced eye-strain, Generic On-Ramps that allow you to send a message into the bus on the consumer's terms, and support for Server-side Itineraries that can place ESB developers back in control of the content of their Itineraries.

Itinerary Designer

Someone once said, "XML is like violence, if it doesn't solve your problem, you're not using enough of it." I'm not going to debate the truth of this one way or another, but I do find it interesting that XML is compared to something that causes such a universal adverse reaction. When color-coded, perfectly indented, and collapsible, I can handle XML. However, at that point I have already resorted to looking at a more human friendly representation of the data instead of the raw data itself.

Those who have downloaded the January CTP of the Guidance, have found themselves in the midst of peace – no XML to be seen (don't worry it's still there if you dig). The January CTP now includes a Visual Studio designer for Itinerary models. Creating Itineraries is now as simple as dragging On-Ramps, Itinerary Services and Off-Ramps into a visual model that can be exported to a repository, or as XML – even mere mortals can do it.

Server-Side Itineraries

Yes, I just said the word repository. Version 1.0 of the guidance was awesome, but it did leave developers with a puzzle: "How do I get the itinerary I need to route this message, and how do I get it to the server?" The answer of course was that you have the XML of the itinerary that you send within the header of the message when submitted to the Itinerary Processing web service.

But where do you get the XML from? How do you know it's valid? Well, with CTP2, you know an itinerary is valid because it was modeled in a designer that validated it before each save and export. With CTP2 the XML can be retrieved from a SQL database (which bears a striking resemblance to the rules set database in BizTalk Server), and applied to the message in a pipeline component.

BizTalk and WCF enthusiast Bram Veldhoen remarked on his blog that it would "be a good idea to have the ESB be responsible for assigning the Itinerary headers." Microsoft apparently agreed, and this is exactly what should be expected from this new version of the ESB Guidance.

New Resolvers

The latest ESB 2.0 CTP adds three new resolvers for resolving itineraries: BRI, ITINERARY, and ITINERARY-STATIC. This means that not only can consumers rely on the ESB to apply itineraries for them; the ESB can do it dynamically. For the ESB Guidance uninitiated, Resolvers are these wonderful classes within the ESB Guidance that can take a configuration string, parse it and execute a query of some sort to look up information necessary for transformation, routing, or some other custom process.

The first is the BRI resolver; a typical resolver connection string would look like this:
BRI:\\policy=SamplePolicy;version=1.1;useMsg=True;

This string, when interpreted by the BRI resolver (the BRE moniker was already taken for a resolver that cannot retrieve itineraries from the repository), will tell the resolver to use the Business Rules policy named SamplePolicy to determine the Itinerary to use for routing. It will also include the message as a fact when calling the Rules.

The second is the ITINERARY resolver; a typical resolver connection string would look like this:
ITINERARY:\\name=Zebra;version=1.0;

This is a static choice of an itinerary named Zebra. Its sister resolver ITINERARY-STATIC does exactly the same thing but is implemented using the Unity Application Block, but that's a discussion to save for another posting.

You would use such resolver connection strings in the configuration of the ESB Itinerary Selector pipeline component, which is part of the ItinerarySelect* family of receive pipelines included with the ESB Guidance 2.0 CTP. Since this is all part of a pipeline, that means that in 2.0, you can create Itinerary On-Ramps that are first class citizens in the ESB which use transports other than an ASMX web service or WCF web service. The possibilities are limited only to the adapters installed.

Getting it Right

The new version of the ESB Guidance brings new features, enhancements, and fixes that really make it feel like a polished product. With version 1 they got it shipped, but with version 2 they're getting it right.

With Microsoft's announcement at PDC this fall and with the continued growth of Amazon's EC2 service and Google's AppEngine service, the industry seems to have people's heads up in the clouds. With this shift of focus, though, comes a myriad of questions about reliability, security, and portability. Potential customers of the cloud want to know that it can indeed be depended on. Executives want to know that the security of data in the cloud will not be compromised. Software engineers want to know that if a certain provider evaporates into thin air, minimal effort will be required to move deployed assets and keep mission critical apps moving.

With so many questions about elastic hosted services, and an as of yet unclear track record for the same, I cannot help but wonder if the cloud computing model will really take hold, or if it will just be a bridge to an even more impressive generation of computing architectures to follow. Maybe it will be both. This discussion then begs the question -- of what that generation will look like that does follow.

Nearly 10 years ago, a program was created that would compel sci-fi geeks, amateur astronomers, scientists, programmers, and scholars to change their screensaver. SETI@home launched in 1999 and over the next 9 years would bring grid computing into the living rooms and dorm rooms of over 5 million people. The original software was an app and screen saver that would use idle computer time to drive the search for extraterrestrial intelligence. It harnessed the untapped power of millions of computers with unrealized potential. It was built as an experiment, to break free of the constraints imposed by a supercomputer. Even hosted clusters have their limits, and some problems go beyond those limits.

With cloud computing the sky is the limit, but what if this world is not enough? What if a single company's data centers won't cut it? What if you want to maintain your data center, while still being able to tap additional resources on demand? What if you wanted to maximize and monetize under-utilized computational resources, instead of just writing them off as depreciating assets each year?

That seemed to be the aim of now defunct CPUShare. It offered users the opportunity to sell their idle CPU time to people who needed computational resources. What if the spirit of this project was matched with the vision of Windows Azure, or the ease of entry of Amazon's EC2. What if it added storage into the mix, RAM, and even bandwidth? What if each of these was currency in a new economy? This new economy would not be comprised of just one company's slice of the cloud; it would be the whole thing.

Crowd sourcing CPU hours might very well be the future, or it may be a pipe dream that will never be possible. It has the same questions of reliability, security, and portability, and it brings with it the question of control. The way the industry deals with the questions about cloud computing today, could very well pave the way for crowd computing to be the driving force behind Web 4.0 and beyond.

With Microsoft's announcement at PDC this fall and with the continued growth of Amazon's EC2 service and Google's AppEngine service, the industry seems to have people's heads up in the clouds. With this shift of focus, though, comes a myriad of questions about reliability, security, and portability. Potential customers of the cloud want to know that it can indeed be depended on. Executives want to know that the security of data in the cloud will not be compromised. Software engineers want to know that if a certain provider evaporates into thin air, minimal effort will be required to move deployed assets and keep mission critical apps moving.

With so many questions about elastic hosted services, and an as of yet unclear track record for the same, I cannot help but wonder if the cloud computing model will really take hold, or if it will just be a bridge to an even more impressive generation of computing architectures to follow. Maybe it will be both. This discussion then begs the question -- of what that generation will look like that does follow.

Nearly 10 years ago, a program was created that would compel sci-fi geeks, amateur astronomers, scientists, programmers, and scholars to change their screensaver. SETI@home launched in 1999 and over the next 9 years would bring grid computing into the living rooms and dorm rooms of over 5 million people. The original software was an app and screen saver that would use idle computer time to drive the search for extraterrestrial intelligence. It harnessed the untapped power of millions of computers with unrealized potential. It was built as an experiment, to break free of the constraints imposed by a supercomputer. Even hosted clusters have their limits, and some problems go beyond those limits.

With cloud computing the sky is the limit, but what if this world is not enough? What if a single company's data centers won't cut it? What if you want to maintain your data center, while still being able to tap additional resources on demand? What if you wanted to maximize and monetize under-utilized computational resources, instead of just writing them off as depreciating assets each year?

That seemed to be the aim of now defunct CPUShare. It offered users the opportunity to sell their idle CPU time to people who needed computational resources. What if the spirit of this project was matched with the vision of Windows Azure, or the ease of entry of Amazon's EC2. What if it added storage into the mix, RAM, and even bandwidth? What if each of these was currency in a new economy? This new economy would not be comprised of just one company's slice of the cloud; it would be the whole thing.

Crowd sourcing CPU hours might very well be the future, or it may be a pipe dream that will never be possible. It has the same questions of reliability, security, and portability, and it brings with it the question of control. The way the industry deals with the questions about cloud computing today, could very well pave the way for crowd computing to be the driving force behind Web 4.0 and beyond.

With Microsoft's announcement at PDC this fall and with the continued growth of Amazon's EC2 service and Google's AppEngine service, the industry seems to have people's heads up in the clouds. With this shift of focus, though, comes a myriad of questions about reliability, security, and portability. Potential customers of the cloud want to know that it can indeed be depended on. Executives want to know that the security of data in the cloud will not be compromised. Software engineers want to know that if a certain provider evaporates into thin air, minimal effort will be required to move deployed assets and keep mission critical apps moving.

With so many questions about elastic hosted services, and an as of yet unclear track record for the same, I cannot help but wonder if the cloud computing model will really take hold, or if it will just be a bridge to an even more impressive generation of computing architectures to follow. Maybe it will be both. This discussion then begs the question -- of what that generation will look like that does follow.

Nearly 10 years ago, a program was created that would compel sci-fi geeks, amateur astronomers, scientists, programmers, and scholars to change their screensaver. SETI@home launched in 1999 and over the next 9 years would bring grid computing into the living rooms and dorm rooms of over 5 million people. The original software was an app and screen saver that would use idle computer time to drive the search for extraterrestrial intelligence. It harnessed the untapped power of millions of computers with unrealized potential. It was built as an experiment, to break free of the constraints imposed by a supercomputer. Even hosted clusters have their limits, and some problems go beyond those limits.

With cloud computing the sky is the limit, but what if this world is not enough? What if a single company's data centers won't cut it? What if you want to maintain your data center, while still being able to tap additional resources on demand? What if you wanted to maximize and monetize under-utilized computational resources, instead of just writing them off as depreciating assets each year?

That seemed to be the aim of now defunct CPUShare. It offered users the opportunity to sell their idle CPU time to people who needed computational resources. What if the spirit of this project was matched with the vision of Windows Azure, or the ease of entry of Amazon's EC2. What if it added storage into the mix, RAM, and even bandwidth? What if each of these was currency in a new economy? This new economy would not be comprised of just one company's slice of the cloud; it would be the whole thing.

Crowd sourcing CPU hours might very well be the future, or it may be a pipe dream that will never be possible. It has the same questions of reliability, security, and portability, and it brings with it the question of control. The way the industry deals with the questions about cloud computing today, could very well pave the way for crowd computing to be the driving force behind Web 4.0 and beyond.

It is no secret that Microsoft has been working on bringing its Enterprise offerings up to date, readying them for the next generation of applications and services, and fixing small pain points that have vexed developers for years. In just a short while, BizTalk Server 2006 R2 will make way for BizTalk Server 2009, and another interesting product from Microsoft will realize next version status. That product is Microsoft Enterprise Service Bus (ESB) Guidance 2.0.

What is an Enterprise Service Bus?

Dmitri Ossipov, a Senior Program Manager for Microsoft working on the ESB Guidance, in his interview on .NET Rocks defined ESB as an "architectural paradigm for policy driven mediation." Nicholas Allen, a Program Manager at Microsoft working on BizTalk Server, argues that "the clearest definition of what companies think ESB means comes from looking at the products that they build." In the case Microsoft's ESB offering we see a solid implementation of the Routing Slip pattern built on top of BizTalk Server sprinkled with ample extensibility points. In the world of the ESB Guidance Routing Slips are called Itineraries, and act like an order placed at a menu of services that is the bus. The ESB Guidance provides flexibility through a loosely coupled design that allows routing and transformation decisions to be made at runtime instead of having to be statically configured at design-time. This enables service composition, dynamic transformation, and adds support for scenarios previously unimaginable in a BizTalk Server environment.

Version 1.0 of the Guidance was a paradigm shift for many BizTalk and .NET developers, but version 2 has the potential to take it to the next level. It introduces some killer new features such as the Itinerary Designer that can reduce XML induced eye-strain, Generic On-Ramps that allow you to send a message into the bus on the consumer's terms, and support for Server-side Itineraries that can place ESB developers back in control of the content of their Itineraries.

Itinerary Designer

Someone once said, "XML is like violence, if it doesn't solve your problem, you're not using enough of it." I'm not going to debate the truth of this one way or another, but I do find it interesting that XML is compared to something that causes such a universal adverse reaction. When color-coded, perfectly indented, and collapsible, I can handle XML. However, at that point I have already resorted to looking at a more human friendly representation of the data instead of the raw data itself.

Those who have downloaded the January CTP of the Guidance, have found themselves in the midst of peace – no XML to be seen (don't worry it's still there if you dig). The January CTP now includes a Visual Studio designer for Itinerary models. Creating Itineraries is now as simple as dragging On-Ramps, Itinerary Services and Off-Ramps into a visual model that can be exported to a repository, or as XML – even mere mortals can do it.

Server-Side Itineraries

Yes, I just said the word repository. Version 1.0 of the guidance was awesome, but it did leave developers with a puzzle: "How do I get the itinerary I need to route this message, and how do I get it to the server?" The answer of course was that you have the XML of the itinerary that you send within the header of the message when submitted to the Itinerary Processing web service.

But where do you get the XML from? How do you know it's valid? Well, with CTP2, you know an itinerary is valid because it was modeled in a designer that validated it before each save and export. With CTP2 the XML can be retrieved from a SQL database (which bears a striking resemblance to the rules set database in BizTalk Server), and applied to the message in a pipeline component.

BizTalk and WCF enthusiast Bram Veldhoen remarked on his blog that it would "be a good idea to have the ESB be responsible for assigning the Itinerary headers." Microsoft apparently agreed, and this is exactly what should be expected from this new version of the ESB Guidance.

New Resolvers

The latest ESB 2.0 CTP adds three new resolvers for resolving itineraries: BRI, ITINERARY, and ITINERARY-STATIC. This means that not only can consumers rely on the ESB to apply itineraries for them; the ESB can do it dynamically. For the ESB Guidance uninitiated, Resolvers are these wonderful classes within the ESB Guidance that can take a configuration string, parse it and execute a query of some sort to look up information necessary for transformation, routing, or some other custom process.

The first is the BRI resolver; a typical resolver connection string would look like this:
BRI:\\policy=SamplePolicy;version=1.1;useMsg=True;

This string, when interpreted by the BRI resolver (the BRE moniker was already taken for a resolver that cannot retrieve itineraries from the repository), will tell the resolver to use the Business Rules policy named SamplePolicy to determine the Itinerary to use for routing. It will also include the message as a fact when calling the Rules.

The second is the ITINERARY resolver; a typical resolver connection string would look like this:
ITINERARY:\\name=Zebra;version=1.0;

This is a static choice of an itinerary named Zebra. Its sister resolver ITINERARY-STATIC does exactly the same thing but is implemented using the Unity Application Block, but that's a discussion to save for another posting.

You would use such resolver connection strings in the configuration of the ESB Itinerary Selector pipeline component, which is part of the ItinerarySelect* family of receive pipelines included with the ESB Guidance 2.0 CTP. Since this is all part of a pipeline, that means that in 2.0, you can create Itinerary On-Ramps that are first class citizens in the ESB which use transports other than an ASMX web service or WCF web service. The possibilities are limited only to the adapters installed.

Getting it Right

The new version of the ESB Guidance brings new features, enhancements, and fixes that really make it feel like a polished product. With version 1 they got it shipped, but with version 2 they're getting it right.