Bram Veldhoen's OLD blog

# re: My beef with the ESB Toolkit 2.0 resolution framework

Heeeeee die Bram....

Switch ENGLISH

Are you telling me that I cannot deploy a property schema of my own and have the resolution framework use those in resolution ?

That could mean the Resolution framework is bound to iterinary... Cause I had a quick look and it seems the Resolution class has many (if not all) of the props an iterinary has...

I wonder by the way how

public bool Success { get; set; }

would resolve using strings ?

# re: My beef with the ESB Toolkit 2.0 resolution framework

Hi Pat! Good to hear from you again.

The Success property is written in the Dictionary<string, string> as string using the following statement:

ResolverDictionary.Add("Resolver.Success", resolution.Success.ToString());

(It got cut out due to brevity; It would have been good if I had mentioned that booleans are also supported as properties. Booleans! woohoo!).

You describe the exact same scenario that I wanted to do (and eventually did do in the ESB.Extensions): using a custom schema that I want to use to resolve instances for (with custom hierarchy of elements and attributes etc.). Check out the SendPipelineServiceResolution class in the ESB.Extensions, this class is defined by a schema and I added some properties and functionalities to it using partial classes.

The SendPipelineService uses this SendPipelineServiceResolution class to resolve. The properties of this SendPipelineServiceResolution object are set during resolution by the BRE (in the ESB.Extensions, a resolver called BRE2).
I tried many ways to do this using the original resolvers, without success. I had a working workaround for it by serializing it into xml in the BRE, and than deserializing it back out in the orchestration, but I really didn't like that solution (slow and cumbersom).

HTH!

Greets,
Bram.

# re: My beef with the ESB Toolkit 2.0 resolution framework

Going to look into the ESB Extensions. Looks pretty interesting. Your resolver dictionary does look interesting and would be more flexible and a better design.

One note I would make is that the resolver dictionary can hold any property though and is not limited to the interfaces you mention. I actually take advantage of this in a sample I built to show how to create a custom message service. On my blog if you are interested.