ESB 2.0 Custom Resolver: Part 2

In part one, we discussed what code was required for a custom resolver. In part two, we will be talking about what steps need to be undertaken in order to have the ESB recognize the new resolver as well as the topic of caching and making the resolver configurable.

Caching

Resolution caching is accomplished using the Microsoft.Practices.ESB.Cache.Cache<T> object. Each resolver maintains its own unique cache. Some resolvers, such as BRE, do not maintain a cache at all, as they are expected to update in real-time when the repository changes.

Adding a resolution to the cache is as simple as calling the Add method of the Cache<T> object with a key and the resolution. A resolution should be unique to its configuration, with that assumption in mind the standard key for a resolution in the cache is its config string. Resolutions are defined as type Dictionary<string, string> the resolution Dictionary should be the second argument in the call to the Add method. Note, that some verification should be done to ensure that the resolution is not empty/corrupted, as it will come back each time the provided config is resolved until the cache expires. The last argument for the Add method is the optional expiration interval. In this implementation a configurable value cacheTimeoutValue was crated that is used to define how long a cache value should persist. A value of 0 denotes that the cache has been disabled.

Retrieving a resolution from the cache requires a call to the Get method of the Cache<T> object. The Get method requires the key (the config string) in order to retrieve the resolution from the cache. The benefit of caching is that it enhances performance when under higher volumes. The database is only queried once per cache expiration interval for a unique configuration. The drawback is that the repository could take one entire expiration interval to update when it is changed. With this balancing act in mind, the expiration interval was made configurable.

Configuration

Configuration includes wiring up the resolver to the ESB and configurable resolution values. The wire-up portion is required for all implementations, so we will start the discussion with that.

Contained in the ESB install is a configuration file called esb.config. This configuration is referenced from both the machine.config and the btsntsvc.exe.config files. The resolution configuration settings are contained in the esb.config file. To wire-up the custom adapter following node needs to be added to the configuration/esb/resolvers node:

The name attribute denotes the Moniker name (see part one for a discussion of Monikers). The type attribute is the fully qualified assembly name for the custom resolver that was created in part one.

To add configurable values for a resolver a resolverConfig node can be added to the aforementioned resolver node:

The configuration can be parsed in the custom resolver class with the following code:

string cacheName = ResolverConfigHelper.ReadResolverConfigByKey(resolverConfig, "cacheName");

To make use of the SQL Cache Manager, it must be configured in the esb.config. Add the following node to the configuration/cachingConfiguration/cacheManagers node:

Future Plans

Future plans for the SQL resolver is to make it more configurable. There are plans to be able to query services by other fields such as Author, Version, etc.

This concludes my two part discussion of custom resolvers in ESB 2.0.

Thursday, March 26, 2009