My SOA Conference Session on ESB is online

by | Feb 27, 2009 | BizTalk Community Blogs via Syndication

 

I had a chance last month to speak at the Microsoft SOA Conference about the latest version of the ESB Guidance for BizTalk Server (version 2.0).  The recordings from that conference have now been posted online.

You can find my ESB session at http://soaconference2009.spaces.live.com/blog/cns!FA6FC7F5DB1C07!136.entry

For a list of all the session recordings, check out

http://soaconference2009.spaces.live.com/default.aspx?wa=wsignin1.0&sa=351061685

Cheers and keep on BizTalking…

Peter

Improving Myself

by | Feb 27, 2009 | BizTalk Community Blogs via Syndication

Those who have known me for any amount of time, know that I have always been a vocal proponent of my employer, Sogeti.  For over 2 years they have been the vehicle by which I’ve advanced my career, and reached out to the developer community.  Unfortunately, the time has come for that relationship to end, and a new one to begin.  The choice was mine alone, and the leadership at Sogeti did their very best to get me to reconsider turning the page, but this is simply the right time for me to begin a new chapter in my career.

In this new chapter, it is time for me to continue to improving myself, and it so happens that improving is exactly what my new employer is all about.  In a few shoud weeks I will be joining the ranks of Improving Enterprises, a consulting firm based in Dallas that provides consulting, training, mentoring, and rural sourcing.  I am thrilled that with this move I will have the chance to help bring the Improving style to BizTalk and WCF projects around the region.  I am also thrilled that I will be joining some of the brightest people I know on their staff.  The list of MVPs alone is enough to boggle the mind, with Caleb Jenkins, David O’Hara, Jef Newsom, and Todd Girvin all on Improving’s rock star staff, and that’s just the MVPs.

I wish everyone at Sogeti nothing but the best, and as always anyone who would like to reach me can do so at [email protected].

ESB Guidance 2.0: Build Loosely Coupled Solutions You Can Be Proud Of

by | Feb 26, 2009 | BizTalk Community Blogs via Syndication

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 version 2.0 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.

Custom Functoid output not able to link to other functoids

by | Feb 25, 2009 | BizTalk Community Blogs via Syndication

I developed a custom functoid and found the weird behavior that wouldn’t allow me to link the output to another functoid. I found the reason here:

http://msdn.microsoft.com/en-us/library/microsoft.biztalk.basefunctoids.functoidcategory.aspx

It states:

FunctoidCategory also determines the functionality restrictions and behaviors possible with the custom functoid. For example, a custom functoid that uses the Logical FunctoidCategory cannot output a string value to the map’s destination schema, but will instead determine whether the destination record is created based on the Boolean value as mentioned at: Logical Functoids.

So using FunctoidCategory.Unknown to display the functoid in the Advanced Functoid category in the VS toolbox modified its behavior to not allow its output to link to other functoids.

BizTalk Adapter Pack V2.0 – x86 or x64 Versions supported

by | Feb 25, 2009 | BizTalk Community Blogs via Syndication

Hi – today I came across a handy Matrix that describes the supported versions for
the Biztalk Adapter Pack v2.0

Handy reference I reckon 🙂

—snip—

Compatibility
Matrix Between 32 and 64-bit Versions of the Adapter, BizTalk Server, and Operating
System

The
following table presents a compatibility matrix between the 32-bit and 64-bit versions
of the operating system, adapter, and .

Oracle
Database Adapter + BizTalk Server

SAP
Adapter + BizTalk Server

Siebel
Adapter + BizTalk Server

Oracle
E-Business Adapter + BizTalk Server

SQL
Adapter + BizTalk Server

Operating
System

32-bit

64-bit

32-bit

64-bit

Yes

N/A

Yes

Yes

32-bit

64-bit

Yes

N/A

Yes

Yes

32-bit

64-bit

Yes

No

Yes

No

32-bit

64-bit

Yes

N/A

Yes

Yes

32-bit

64-bit

Yes

N/A

Yes

Yes

Legend

%u00b7         Yes =
Supported.

%u00b7         No =
Not supported.

%u00b7         N/A =
Not Applicable.