December 2007 - Posts

ESB Guidance...part 3
13 December 07 09:02 PM | logical | 4 comment(s)

Itinerary Processing

So what does ESB Guidance offer beyond the management and monitoring aspect?

The notion of itinerary processing was all new to me, and as I said in previous posts, I didn't really understand the concept at first. However, now that I do, I think of this as, by far, the coolest thing about the ESB Guidance.

Although BizTalk is flexible and configurable, when you've deployed your schemas, maps orchestrations etc, it all takes on a more static state. Furthermore, all those artifacts are compiled into assemblies, and you'll have binary references all over the place. These assembly references are of course internal, and doesn't necessary make your BizTalk solution less loosely coupled, but it will however have an effect on your overall productivity.

Normally, a system consuming a service hosted in BizTalk, would have no knowledge of how that call would be executed on the other side of that end-point. The mechanism behind the itinerary processing lets the consumer of the service describe the process, and pass that description to the service. A pipeline will then resolve the itinerary and proceed with the instructions.  

The itinerary describes a composition of services to be executed, such as transformation, routing and dynamic end-point resolution. Each of which works with a set of resolvers, that will provide the necessary input for that service.

It's important to understand the relationship between the services and the resolvers. Each resolver returns resolver facts as a property/value Dictionary defined in the Resolution class. This class contains properties such as TransportType and TransportLocation used by any of the adapter providers, and TransformType used for the Transform service.

A Uddi resolver, will return a preset property/value dictionary which only suits the adapter provider for dynamic end-point resolution. The BizTalk Rule Engine resolver howerver, is more dynamic and can be used with any adapter provider or service. This is since the user (developer) sets all the Resolver facts within the BRE, such as the name of a mapping file, which can then be used with the transformation service.

The help describes in great detail how’d you go about building your own Services, Resolvers and Adapter providers.

ESB Guidance part 4

Filed under: , ,
ESB Guidance…part 2
07 December 07 06:28 PM | wmmihaa | 1 comment(s)

Management and monitoring

Eventually I got through with the installation procedure, and got the portal up and running.

Being a BizTalk developer you are pretty much neglected from any kind of user-friendly experience. -This looks really good, and it seems easy to manage. Exceptions are caught, and nicely presented in various graphs and lists. Alerts can be set up and later subscribed to. BizTalk receive locations and send ports can be published to the uddi server and much more.    

In my opinion, there are two main advantages with this portal. First of all, in my experience, BizTalk server is usually installed down in the deepest and darkest of catacombs, behind several firewalls and as far away from any user as possible. This makes it somewhat challenging for the support personnel since they need to use the BizTalk Administration Console.  The BizTalk Administration Console, as you may know, need to to connect to the management database directly, wish pretty much puts our support guys behind the same firewalls. However, using the ESB portal, you'll still need the BizTalk console, but you might at least delegate some of the operational tasks to colleagues on the other side of the wall.

The second benefit is all about exception handling. Usually, we need to handle exceptions differently depending whether it is caught in a mapping, pipeline or orchestration. ESB Guidance solves this by relying on failed message routing. Exceptions are routed to the All.Exceptions Send Port (SQL Adapter) which stores the data in the EsbExceptionDb database. From this source, all exceptions are presented in a unified way in the portal. - Sweet!

ESB Portal - Home


ESB Guidance part 3

Filed under: , ,
ESB Guidance…part 1
01 December 07 06:20 PM | wmmihaa

Christmas came early this year...

I first heard of ESB Guidance at the SOA Conference in Redmond.  And even though I attended Marty Wasznickys sessions, it took me a while to fully understand the concept. I mean, just looking at the ESB portal and the Exception Handling Framework, what more could a BizTalk developer ask for...

Marty kept on talking about Intineries, On- and Off Ramps and I, still focusing on the portal, couldn't really grasp it all.

Later, I got home and waited for the November release to be announced. And much like a kid, opening his first present on Christmas, I downloaded the ESB Guidance msi file, and got on with the installation.

This experience reminds me of being seven years old and wishing for a 3000+ pieces model ship for X-mas.  Ripping the paper of the package,  I didn't spear no time taking on the challenge of building the RMS Titanic, much without the help of the guided instructions I might add. Needless to say, the result was a disaster. But what do you know, some 30 years later, I came to learn from this experience.

 You see, as it turns out, double-clicking that installation file was not enough. You have to proceed through a very tedious (but well documented) installation procedure before you get to taste the sweetness of ESB Guidance. Take my advice, be thorough and read the installation instruction carefully. 

That said, -It's totally worth it!

ESB Guidance…part 2


Filed under: , , ,

This Blog


    MVP - Microsoft Most Valuable Professional BizTalk User Group Sweden BizTalk blogdoc

    Follow me on Twitter Meet me at TechEd


    Locations of visitors to this page


    The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.