MSDN Code Gallery

Duck Typing with Castle

EltonStoneman — Wed, 21 Oct 2009 07:59:24 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

David Meyer has a neat duck typing library for .NET which I’ve been looking at as I had a requirement to treat objects of various types in the same way. They all expose a “Value” property, but don’t implement an interface.

The library does more than I needed so I put together a quick duck typing implementation which just lets me treat an instance of an object which tacitly implements an interface, as a true implementation of the interface. In this example I can access BespokeDateTime and BespokeInt as IHasValue:

Using Castle’s Dynamic Proxy, this is simple to do – just requiring you to generate an interface proxy with a custom interceptor. The interceptor invokes the interface method on the real object, so you effectively wrap an instance in an interface it doesn’t explicitly implement:

BespokeDateTime bespoke = new BespokeDateTime(new DateTime(2000, 1, 1));

IHasValue duck = DuckType.As<IHasValue>(bespoke);

Console.WriteLine(duck.Value);

- or using an object extension to hide the implementation:

bespoke.As<IHasValue>().Value;

Iterating over collections is much cleaner with duck typing – if I have a collection that contains both BespokeDateTime and BespokeInt objects, to get all their values I can use:

foreach (object obj in GetObjects())

{

Assert.IsNotNull(DuckType.As<IHasValue>(obj).Value);

}

- compared to casting each object:

foreach (object obj in GetObjects())

{

BespokeDateTime bespokeDateTime = obj as BespokeDateTime;

if (bespokeDateTime != null)

{

Assert.IsNotNull(bespokeDateTime.Value);

}

else

{

BespokeInt bespokeInt = (BespokeInt) obj;

Assert.IsNotNull(bespokeInt.Value);

}

Use with caution over large collections, as there is a noticeable performance hit in using the duck type. Over 500,000 items the duck-typed code takes 40-50 times as long as the casting code, averaging 8 seconds to 0.2 seconds, with duck-typing by extension taking marginally longer again:

The full code (all 34 lines – including validation that the type to duck does tacitly implement the interface) is on MSDN Code Gallery here: Duck Typing with Castle.

WCF Personalization Provider for ASP.NET

EltonStoneman — Tue, 15 Sep 2009 19:49:24 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

The ASP.NET Web Part framework uses a plug-in framework for loading and saving personalization data to a persistent source. Out of the box, a SQL Server data source is provided (via the aspnet_regsql tool), along with a SQL personalization provider – specified in the system.web configuration section:

<add name="SqlPersonalizationProvider"

type="System.Web.UI.WebControls.WebParts.SqlPersonalizationProvider"

connectionStringName="local"

applicationName="WcfPersonalizationSample" />

It's painless to set up and gets you running Web Part-enabled sites quickly. But if your Web servers and database servers are separated by a physical boundary with app servers in between, you can't use the SQL provider directly from the ASP.NET application and will need to write a custom personalization provider.

Exposing the existing SQL personalization store through a custom WCF provider is a straightforward option – so your app server hosts a WCF service which itself uses the SQL personalization provider, and the Web server uses the WCF service through the custom provider. Although the implementation is fairly trivial, there are a couple of issues to work around:

PersonalizationProvider is an abstract class which requires you to implement methods with out and ref parameters. You'll need to write methods with different signatures to work over WCF;
SqlPersonalizationProvider has methods for loading personalization data as byte arrays, which are useful for the WCF service. To access them you'll need another custom provider which inherits from SqlPersonalizationProvider, as the underlying methods are protected.

I've worked this through as a sample on MSDN Code Gallery: WCF Personalization Provider Sample.

To use it, the WCF service host needs to be configured to use the custom provider which wraps the SQL store, and a connection string entry for the data store:

<add name="local"

connectionString="Data Source=.;Initial Catalog=WcfPersonalizationSample;Integrated Security=True"

providerName="System.Data.SqlClient" />

</connectionStrings>

<system.web>

<add name="PersonalizationServiceProvider"

type="WcfPersonalizationProvider.PersonalizationServiceProvider"

connectionStringName="local"

applicationName="WcfPersonalizationSample" />

</providers>

</personalization>

</webParts>

...

(Note that this is using ASP.NET functionality in the WCF service, but you do not need to set the WCF service up for ASP.NET compatibility mode.)

The Web site need to be configured to use the custom provider which accesses the WCF service, and a service client entry for the WCF service:

<add name="WcfPersonalizationProvider"

type="WcfPersonalizationSample.ServiceClient.WcfPersonalizationProvider"

applicationName="WcfPersonalizationSample" />

</providers>

</personalization>

</webParts>

...

<endpoint address="http://localhost/PersonalizationService.svc"

binding="basicHttpBinding"

contract="PersonalizationService.IPersonalizationService"

name="BasicHttpBinding_IPersonalizationService" />

</client>

Both providers need to specify the same applicationName value, and your Web Part personalization, for shared and user scopes, will work without the Web servers accessing the database.

FluentHtmlTextWriter

EltonStoneman — Fri, 11 Sep 2009 00:32:28 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

Keeping up the fluent work, I've put together a fluent interface which wraps the framework HtmlTextWriter. For ASP.NET MVC, this makes generating HTML in extension methods to HtmlHelper safer than string.Format() and more readable than HtmlTextWriter:

public static string Image(this HtmlHelper helper, string imageRelativeUrl, string altText)

{

return FluentHtmlTextWriter.Begin()

.WriteTag(HtmlTextWriterTag.Img)

.WithAttribute(HtmlTextWriterAttribute.Src, GetImageUrl(imageRelativeUrl))

.WithAttribute(HtmlTextWriterAttribute.Alt, altText)

.End();

}

The equivalent using HtmlTextWriter is:

public static string Image(this HtmlHelper helper, string imageRelativeUrl, string altText)

{

StringBuilder htmlBuilder = new StringBuilder();

HtmlTextWriter writer = new HtmlTextWriter(new StringWriter(htmlBuilder));

writer.AddAttribute(HtmlTextWriterAttribute.Src, GetImageUrl(imageRelativeUrl));

writer.AddAttribute(HtmlTextWriterAttribute.Alt, altText);

writer.RenderBeginTag(HtmlTextWriterTag.Img);

writer.RenderEndTag();

writer.Flush();

return htmlBuilder.ToString();

}

Unlike the framework writer, you're not constrained to specify attributes in any particular order, and tags which aren't nested can be written with a single WriteTag(), rather than BeginTag() and EndTag() calls. The writer copes with multi-level tag hierarchies - this sample builds a Superfish CSS menu:

FluentHtmlTextWriter writer = FluentHtmlTextWriter.Begin();

writer.BeginTag(HtmlTextWriterTag.Ul)

.WithAttribute(HtmlTextWriterAttribute.Id, "menu.Name")

.WithAttribute(HtmlTextWriterAttribute.Class, "sf-menu sf-vertical");

.BeginTag(HtmlTextWriterTag.Li)

.BeginTag(HtmlTextWriterTag.A)

.WithAttribute(HtmlTextWriterAttribute.Class, "sf-with-ul")

.WithAttribute(HtmlTextWriterAttribute.Href, "#")

.WithValue("Link 1")

.WriteTag(HtmlTextWriterTag.Span)

.WithAttribute(HtmlTextWriterAttribute.Class, "sf-sub-indicator")

.WithValue("»")

.EndTag()

.EndTag();

string html = writer.End();

Assert.AreEqual("<ul id=\"menu.Name\" class=\"sf-menu sf-vertical\">\r\n\t<li><a class=\"sf-with-ul\" href=\"#\">Link 1<span class=\"sf-sub-indicator\">»</span></a></li>\r\n</ul>",

html);

The HtmlTextWriter equivalent is unthinkable.

Patrik Hägne has an alternative fluent HtmlTextWriter implementation, which is nicely put together, but I wanted slightly different functionality. Firstly I wanted to get the HTML string from the writer directly, without needing to instantiate a StringBuilder and StringWriter. Secondly I wanted minimal new code – Patrik uses a separate class to manage writing attributes, and has specific functions for known tag types. Thirdly, I didn't really like Patrik's syntax, with the need to specify the tag type when you write an end tag – and when tags aren't nested, I wanted to write them in a single unit:

string html = FluentHtmlTextWriter.Begin()

.WriteTag(HtmlTextWriterTag.Span)

.WithAttribute(HtmlTextWriterAttribute.Id, "id_span")

.WithValue("contents_span")

.End();

Assert.AreEqual("<span id=\"id_span\">contents_span</span>", html);

My version is on MSDN Code Gallery here: FluentHtmlTextWriter. It works by building up a list of actions when you start writing a tag, and flushing them in the correct order to an internal HtmlTextWriter when you start writing the next tag. When you call End() it flushes the internal writer and outputs its contents. An alternative constructor lets you write directly to an output stream, in which case you can Flush() the writer and don't need to call End().

The current implementation only deals with basic tag, attribute and style functionality, and doesn't include optional HTML encoding overloads. It's only 75 lines of code, and extending it should be trivial.

There is a negligible performance hit in using FluentHtmlTextWriter – running the image tag generation code above 20,000 times on my dev machine, the fluent version takes between 0.01and 0.02 seconds longer than the framework version (on average 0.07 seconds compared to 0.05).

Fluent DAL Mapping

EltonStoneman — Tue, 08 Sep 2009 07:32:20 GMT

If you spend some time using Fluent NHibernate, you’ll want to use its neat style of mapping for all data access, even when you’re working against traditional DALs. I’ve put a sample up on MSDN Code Gallery for this scenario, using a fluent style of mapping between domain objects and data readers populated by stored procedure calls.

The interface is very similar to FNH, with a mapping class used for each domain entity – this is a simple mapping class:

public class PostCodeMap : DataReaderMap<PostCode>

{

public PostCodeMap()

{

Map(x => x.InwardCode, "PS_IN");

Map(x => x.OutwardCode, "PS_OUT");

}

The string constants define the column names expected in the data reader, and the base class takes care of running the map. For more complex entities, DataReaderMap also includes mapping via a conversion function:

Map<string, bool>(x => x.Activated, "AccountActivated", Legacy.FromBoolean);

- where the mapping specifies to and from types, and a delegate to invoke for the conversion (in this case, a method which converts a legacy string representation of a boolean – Y/N – to a bool).

For composite objects, the base map includes referencing, for cases where the child entity is loaded from the same data reader as the parent entity:

References(x => x.Address, new AddressMap());

Where the child entity is read from a separate data reader, then the composition needs to be done outside of the map in a repository or an assembler component. The Load class isolates calling the stored procedure, so you get a fluent interface for populating domain objects, and collections of objects:

public User GetUser(Guid userId)

{

//populate basic details:

User user = Fluently.Load<User>().With<UserMap>()

.From<GetUser>(i => i.UserId = userId,

x => x.Execute());

//add accounts:

user.Accounts = Fluently.Load<List<Account>>().With<AccountMap>()

.From<GetUserAccounts>(i => i.UserId = userId,

x => x.Execute());

return user;

}

The From() call specifies the type of stored procedure, an action to populate the object, in this case setting up the UserId parameter, and a function to call which returns a data reader, in this case Execute().

The full sample is on the gallery here: Fluent DAL Mapping . It’s a simple task to extend the sample to load datasets, or to populate update procedure calls from entities. If your database is sufficiently conventional this could be extended to provide FNH-style auto-mapping, reflecting over entities and using conventions to map properties to column names.

Using PowerShell in BizTalk Post-Processing Scripts

EltonStoneman — Mon, 08 Jun 2009 20:58:18 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

Often in BizTalk deployments you need to do additional work after installation. Typically your full install process may need to:

Install BizTalk artifact assemblies to the GAC
Install application dependencies to the GAC
Register an application source name in the registry, for logging to the Event Log
Create FILE send or receive locations on the local filesystem
Add application store configuration settings to Enterprise Single Sign-On (SSO)
Add log4net configuration settings to BTSNTSvc.exe.config

You can achieve this with a single BizTalk installer by configuring resources and post-processing scripts, and exporting an MSI from the application. Various scripting languages are supported in BizTalk installations (batch files, VBScript etc.), except the most logical – PowerShell, which gives first-class support for the filesystem, the registry, XML files and .NET objects. You can still use PowerShell by including scripts as resources, and using a batch file as the post-processing script, which acts as a harness to call the PowerShell scripts.

This walkthrough addresses all the points above. The completed BizTalk application is on MSDN Code Gallery here: BizTalk PowerShell Deployment Sample – import and install the MSI to deploy with the PowerShell script, or browse the ZIP file to see the scripts and resources.

1. Install BizTalk artifact assemblies to the GAC

This is straightforward, set the resource option "Add to the global assembly cache on MSI file install" to true – this happens by default if you add a BizTalk Assembly resource in the Administration Console:

Using the command line though, this is not the default option so you need to explicitly set –Options:GacOnInstall in BTSTask:

btstask AddResource

-ApplicationName:PowerShellSample

-Type:BizTalkAssembly

-Options:GacOnInstall

-Source:PowerShellSample.Schemas.dll

-Destination:%BTAD_InstallDir%\PowerShellSample.Schemas.dll

2. Install application dependencies to the GAC

As 1), except the resource type is System.BizTalk:Assembly (in BTSTask you can omit "System.BizTalk"). The command requires the same flag to add to the GAC on install:

btstask AddResource

-ApplicationName:PowerShellSample

-Type:Assembly

-Options:GacOnInstall

-Overwrite

-Source:.\Dependencies\SSOConfig.dll

-Destination:%BTAD_InstallDir%\Dependencies\SSOConfig.dll

In this case, I'm installing the SSOConfig assembly (from SSO Config Tool) which provides static .NET classes for accessing the SSO application configuration store. The Overwrite flag is set in case the resource already exists in another application.

3. Register an application source name in the registry, for logging to the Event Log

To log to the Application event log with your own source name, you need to add a registry key with the app name, and the name of the handler:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Application\PowerShell.Sample

In PowerShell, this is done in using the New-Item cmdlet to create the key, and New-ItemProperty to set the key value:

New-Item -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\Eventlog\Application\PowerShellSample' -Force

New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\Eventlog\Application\PowerShellSample' -Name 'EventMessageFile' -PropertyType ExpandString -Value 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\EventLogMessages.dll' –Force

(HKLM: is a PowerShell drive mapped to HKEY_LOCAL_MACHINE, and the –Force flag overwrites existing values).

To execute the PowerShell script on install, we need a batch file which BizTalk can run as a post-processing script. The batch file is very simple, just separating install and uninstall logic to individual PowerShell scripts, and redirecting script output to a log file:

cd "%BTAD_InstallDir%\Deployment"

if "%BTAD_InstallMode%" == "Install" ( powershell ".\PowerShellSample.Install.ps1" >> PowerShellSample.Install.ps1.log )

if "%BTAD_InstallMode%" == "Uninstall" ( powershell ".\ PowerShellSample.Uninstall.ps1" >> PowerShellSample.Uninstall.ps1.log )

Both the CMD and PS1 files need to be added as resources to the BizTalk application. The PS1 files are of type BizTalk:File, and the CMD harness is of type BizTalk:PostProcessingScript:

btstask AddResource

-ApplicationName:PowerShellSample

-Type:File

-Source:.\Deployment\PowerShellSample.Install.ps1

-Destination:%BTAD_InstallDir%\Deployment\PowerShellSample.Install.ps1

btstask AddResource

-ApplicationName:PowerShellSample

-Type:PostProcessingScript

-Source:.\Deployment\PowerShellSample.PostProcessing.cmd

-Destination:%BTAD_InstallDir%\Deployment\PowerShellSample.PostProcessing.cmd

4. Create FILE send or receive locations on the local filesystem

If you need to create static file locations, the same New-Item cmdlet is used with the filesystem provider. Specify the full path for the directory and any intermediate directories will be created if they don't exist. Use the –Force flag to suppress warnings if the directory already exists:

New-Item –Path 'c:\receiveLocations\x\y\z' -ItemType Directory –Force

Note that the resources in the BizTalk application are copies rather than references, so if you modify your PS1 files, you'll need to update the resource (in the Administration Console, select the resource and use Modify... Refresh, or re-run the BTSTask command).

5. Add settings to Enterprise Single Sign-On (SSO)

If you're using SSO to store group-wide application config, you can create or export an XML file of the settings using SSO Config Tool. We add the .ssoconfig file as a File resource to the application, then in the install script use PowerShell to call a .NET method to import the settings using the SSOConfig.SSOApplication class. The SSOConfig assembly is a resource which has already been deployed to the GAC by this point in the installation:

[Reflection.Assembly]::Load('SSOConfig, Version=1.1.0.0, Culture=neutral, PublicKeyToken=656a499478affdaf')

$configPath = [IO.Path]::Combine($env:BTAD_InstallDir, 'Deployment\PowerShellSample.ssoconfig')

$app = [SSOConfig.SSOApplication]::LoadFromXml($configPath)

$app.SaveToSSO()

Note that the PowerShell script has access to all the environment variables set by BizTalk on the install – accessed by prefixing $env: to the variable name, as we do here to get the installation directory from the installer ($env:BTAD_InstallDir).

6. Add settings to BTSNTSvc.exe.config

Modifying XML is straightforward in PowerShell. We want to configure an Event Log appender in the BizTalk service config file by adding the following XML:

</configSections>

</layout>

</appender>

<appender-ref ref="Sixeyed.CacheAdapter.EventLogAppender" />

</logger>

</log4net>

The Get-ItemProperty cmdlet can read the BizTalk install path from the registry, then Get-Content reads the file – casting it to XML for subsequent processing:

$installPath = Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\BizTalk Server\3.0' -Name 'InstallPath'

$btsConfigPath = [IO.Path]::Combine($installPath.InstallPath, 'BTSNTSvc.exe.config')

$xml = [xml] (Get-Content $btsConfigPath)

On a fresh install, the config file is quite bare and doesn't include a <configSections> element, so in that case we need to add both <configSections> and <log4net> nodes. We can't guarantee that other solutions haven't already modified the config file though, so <configSections> may exist, and <log4net> may also exist – in which case, we just need to add our specific appender and logger values (log4net allows you to define multiples of these in config, and we specify names which we can expect to be unique).

To achieve this, the script checks for each element first, creates it if it doesn't exist, then adds the specific settings:

$configSections = $xml.SelectSingleNode('configuration/configSections')

if ($configSections -eq $null)

{

$configSections = $xml.CreateElement('configSections')

$firstChild = $xml.configuration.get_FirstChild()

$xml.configuration.InsertBefore($configSections, $firstChild)

}

$log4netSection = $configSections.SelectSingleNode('section[@name="log4net"]')

if ($log4netSection -eq $null)

{

$log4netSection = $xml.CreateElement('section')

$log4netSection.SetAttribute('name', 'log4net')

$log4netSection.SetAttribute('type', 'log4net.Config.Log4NetConfigurationSectionHandler, log4net, Version=1.2.10.0, Culture=neutral, PublicKeyToken=1b44e1d426115821')

$configSections.AppendChild($log4netSection )

}

...

Finally the updates are saved over the original file:

$xml.Save($btsConfigPath)

Limitations

The main limitation with any post-processing script, is that the target environment selected for the install is not available. If you have multiple bindings files, the environment selected at runtime is only alive for the duration of the MSI import – the install has no reference to it, and there's no record made in the management database (not that I can see, please correct me if there is). This means you can't switch your script based on environment (e.g. to use different SSO config settings for System Test and Production). If that's a serious restriction you may prefer to create different MSIs per-environment in your build process, each containing the correct bindings file and scripts.

Specific to this approach, you need to have PowerShell installed on all the target machines, and configured to allow script execution (by default, scripts are not permitted to execute, as a security measure). Hopefully this is becoming the norm. Security also needs to be considered – the sample app writes to the registry and to SSO, so the installing context needs to have explicit permissions. The BizTalk installer runs under a separate security context from the installing user (by a trial-and-error process, this is NT AUTHORITY\ANONOYMOUS LOGON in my Server 2003 VM), so if you're amending SSO you'll need to set your SSO Administrators group membership correctly.

Benefits

The completed PowerShell scripts should be straightforward to read and maintain. All the post-installation requirements are implemented using a single technology, and many of the functions are reusable and could easily be parameterised and moved to a central script. The script is easy to test outside of the installer runtime, either manually using a batch file as a test harness (which sets up the relevant environment variables and then calls the post-processing file), or worked into an automated unit test.

The approach is not limited to BizTalk installations, so similar tasks for .NET deployments which are currently done with custom assemblies or Wix script can be isolated in the same way. With BizTalk and .NET installs using the same technology, you'll build up a library of high-quality, reusable PowerShell scripts.

I also like having the scripts deployed as part of the install, so in combination with the log files, you can see exactly what's been done to your environment and modify if necessary.

Extensions

With native cmdlets and community scripts, together with WMI, XML and .NET code, you can achieve any desired functionality with PowerShell scripts, and have them rapidly developed and tested. So you can easily add code to update version numbers in config files, remove your assemblies from the GAC on uninstall, access performance counters etc. And PowerShell scripts are just plain text so you can extract them into a T4 template and generate different scripts for different environments in your build process.

Managing Concurrency over Service Boundaries

EltonStoneman — Thu, 16 Apr 2009 04:15:04 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

Managing concurrency within an application boundary can be straightforward where you own the database schema and the application's data representation. By adding an incrementing lock sequence to tables and holding the current sequence in entity objects, you can implement optimistic locking at the database level without a significant performance hit. At the service level, the situation is more complicated. Even where the database schema can be extended, you wouldn't want the internals of concurrency management to be exposed in service contracts, so the lock sequence approach isn't suitable.

An alternative pattern is to compute a data signature representing the retrieved state of an entity at the service level, and flow the signature alongside the entity in Get services. On Update calls, the original data signature is passed back and compared to the current signature of the data; if they differ then there's been a concurrency violation and the update fails. The signature can be passed as a SOAP header across the wire so it's not part of the contract and the optimistic locking strategy is transparent to consumers.

The level of transparency will depend on the consumer, as it needs to retrieve the signature from the Get call, retain it, and pass it back on the Update call. In WCF the DataContract versioning mechanism can be used to extract the signature from the header and retain it in the ExtensionData property of IExtensibleDataObject. The contents of the ExtensionData property are not directly accessible, so if the same DataContract is used on the Get and the Update, and the signature management is done through WCF extension points, then concurrency control is transparent to users.

I've worked through a WCF implementation for this pattern on MSDN Code Gallery here: Optimistic Locking over WCF. The sample uses a WCF behavior on the server side to compute a data signature (as a hash of the serializable object – generating a deterministic GUID from the XML string) and adds it to outgoing message headers for all services which return a DataContract object. On the consumer side, a parallel behaviour extracts the data signature from the header and adds it to ExtensionData, by appending it to the XML payload and using the standard DataContractSerializer to extract it.

The update service checks the data signature passed in the call with the current signature of the object and throws a known FaultException if there's been a concurrency violation, which the WCF client can catch and react to:

Sixeyed.OptimisticLockingSample

The sample solution consists of four projects providing a SQL database for Customer entities, WCF Get and Update services, a WCF client and the ServiceModel library which contains the data signature behaviors. DataSignatureServiceBehavior adds a dispatch message formatter to each service operation, which computes the hash for any DataContract objects being returned, and adds it to the message headers. DataSignatureEndpointBehavior on the client adds a client message formatter to each endpoint operation, which extracts the hash from incoming calls, stores it in ExtensionData and adds it back to the header on outgoing calls.

Concurrency checking is done on the server side in the Update call, by comparing the given data signature to the signature from the current object state:

Guid dataSignature = DataSignature.Current;

if (dataSignature == Guid.Empty)

{

//this is an update method, so no data signature to

//compare against is an exception:

throw new FaultException<NoDataSignature>(new NoDataSignature());

}

Customer currentState = CustomerEntityService.Load(customer);

Guid currentDataSignature = DataSignature.Sign(currentState);

//if the data signatures match then update:

if (currentDataSignature == dataSignature)

{

CustomerEntityService.Update(customer);

}

else

{

//otherwise, throw concurrency violation exception:

throw new FaultException<ConcurrencyViolation>(new ConcurrencyViolation());

}

A limitation of the sample is the use of IExtensibleDataObject to store the data signature at the client side. Although this is fully functional and allows a completely generic solution, it relies on reflection to extract the data signature and add it to the message headers for the update call, which is a brittle option. Where you have greater control over the client, you can use a custom solution which will be more suitable – e.g. creating and implementing an IDataSignedEntity interface, or if consuming the services in BizTalk, by using context properties.

Making Logging Cheaper with Lambda Expressions

EltonStoneman — Thu, 16 Apr 2009 04:08:28 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

The venerable log4net library enables cheap instrumentation with configured logging levels, so logs are only written if the log call is on or above the active level. However, the evaluation of the log message always takes place, so there is some performance hit even if the log is not actually written. You can get over this by using delegates for the log message, which are only evaluated based on the active log level:

public static void Log(LogLevel level, Func<string> fMessage)

{

if (IsLogLevelEnabled(level))

{

LogInternal(level, fMessage.Invoke());

}

Making the delegate call with a lambda expression makes the code easy to read, as well as giving a performance saving:

Logger.Log(LogLevel.Debug,

() => string.Format("Time: {0}, Config setting: {1}",

DateTime.Now.TimeOfDay,

ConfigurationManager.AppSettings["configValue"]));

For simple log messages, the saving may be minimal, but if the log involves walking the current stack to retrieve parameter values, it may be worth having. The sample above writes the current time and a configuration value to the log, if set to Debug. With the log level set to Warn, the log isn't written. Executing the call 1,000,000 times at Warn level consistently takes over 3.7 seconds if the logger call is made directly, and less than 0.08 seconds if the Lambda delegate is used:

With a Warn call, the log is active and the direct and Lambda variants run 5,000 calls in 8.6 seconds, writing to a rolling log file appender:

I've added the logger and test code to the MSDN Code Gallery sample: Lambda log4net Sample, if you're interested in checking it out.

Alternative SOAP Transport for LoadGen

EltonStoneman — Wed, 25 Feb 2009 00:33:57 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

Using LoadGen 2007 to submit messages with a complex SOAP header, I had a strange issue with the standard SOAP transport. The SOAP transport has two parameters for wrapping the input file into a SOAP envelope:

<URL>http://x/ESB.ItineraryServices.Response/ProcessItinerary.asmx</URL>

<SOAPHeader>SOAPAction: "http://microsoft.practices.esb/Process/SubmitRequestResponse"</SOAPHeader>

<IsUseIntegratedAuth>False</IsUseIntegratedAuth>

</Parameters>

- note the ellipses above are for brevity and are not in the actual LoadGen config file.

When the transport gets called, it opens an HTTP request and sends the SOAP envelope by writing three sets of byte arrays to the request stream: the value of SOAPEnvPrefix, the contents of the input file, then the value of SOAPEnvPostfix. All the byte arrays are encoded to the value specified by DstEncoding. When I used this configuration to send a message it was being rejected by the endpoint as a bad request. Trapping the request with Wireshark, it looked like this:

It looks as though LoadGen has injected an ellipsis before each part of the message it built – the envelope prefix, the input file contents and the envelope postfix all start with an ellipsis in which is not in the original. The request is malformed and rejected by the service.

Initially I thought this was something strange in how Wireshark was showing the results and wasn't actually part of the message, so I checked further and found that the XML escapes weren't set correctly. The SOAP header is an ESB Guidance itinerary which contains escaped XML for CDATA sections – to enter it as the SOAPEnvPrefix parameter meant escaping the escapes, so <!CDATA[]> becomes &lt;!CDATA[]&gt; in the parameter and is rendered correctly. But the issue remained, and so did the ellipses. Copying the full request into Web Service Studio produced the same result, but cutting out the ellipses meant it processed correctly.

With time accumulating on what should have been a simple task, I checked out the SOAPTransport code and could see nothing that was causing this. Debugging the call didn't show any ellipsis characters being written, and modifying it to produce a single string of the header, body and footer before encoding made no difference. In the end I created a modified transport which takes a full SOAP envelope as the input file, doing away with the envelope parameters altogether.

This worked fine, didn't render any ellipses – although the code is very similar to LoadGen's SOAPTransport class – and was happily processed. It has the advantage that you can capture a full message with Wireshark, save it and use it in LoadGen without having to extract the header. It's on the MSDN Code Gallery here: Sixeyed.Samples (Sixeyed.Samples.LoadGen.Transports.AlternativeSOAPTransport).

Configuration is very similar to the standard transport, just specify the assembly and remove the SOAP envelope parameters:

<Assembly>Sixeyed.Samples.dll/Sixeyed.Samples.LoadGen.Transports.AlternativeSOAPTransport</Assembly>

</Transport>

…

<URL>http://x/ESB.ItineraryServices.Response/ProcessItinerary.asmx</URL>

<SOAPHeader>SOAPAction: "http://microsoft.practices.esb/Process/SubmitRequestResponse"</SOAPHeader>

<IsUseIntegratedAuth>False</IsUseIntegratedAuth>

</Parameters>

But I'm still puzzled about those ellipses from the standard SOAP transport.

Generic WCF Error Handler for ESB Guidance

EltonStoneman — Tue, 20 Jan 2009 14:43:29 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

The management portal for ESB Guidance is an excellent tool which displays information on faults generated during the processing of messages through the ESB. It also exposes Web and WCF services for logging your own faults to the exception database, so you can record exceptions that occur in your own service providers and use the portal as a single view over the health of your SOA stack.

The SubmitFault method of the ExceptionManagement service takes a FaultMessage object which must be correctly configured with Header and FaultException properties. It takes some trial-and-error to work out what needs populating – if any properties are missing or invalid, your fault won't be logged. I've put together a sample error handler on MSDN Code Gallery which populates a call correctly: ESB Guidance Error Handler, which you can use as-is in your WCF services, or as a basis for your own handler.

In the sample, the error handler is available to your service so you can manually log a fault for any exceptions that you catch, and you can also configure it as a service behaviour so it will log any uncaught exceptions in your WCF service. A sample service and client are provided for demonstration – set up the SampleService as a virtual directory and run SampleClient (you'll need the ESB Guidance Exception Management installed).

To use the ServiceProviderErrorHandler add a config section in your web.config to specify how faults are logged:

<section

name="serviceProviderErrorHandlerConfiguration"

type="ESBGuidanceErrorHandler.Configuration.ServiceProviderErrorHandlerConfiguration, ESBGuidanceErrorHandler"/>

</configSections>

<serviceProviderErrorHandlerConfiguration

exceptionHandlingUrl="http://localhost/ESB.ExceptionHandlingServices/ExceptionHandling.asmx"

bizTalkApplication="BizTalk Application 1"

faultCode="50054"

errorType="Service Provider exception"

failureCategory="0"

faultGeneratorName="ESBGuidanceErrorHandler">

</serviceProviderErrorHandlerConfiguration>

This identifies the location of the ExceptionHandling service (the sample uses the SOAP entry point, but it's a simple change to use the WCF version as they have the same signature) and the descriptive text to categorise errors being logged, which will be shown in the portal. Note that the specified BizTalk Application must exist and the fault generator name is limited to 50 characters. Other values can contain any identifiers you like.

With the config specified, it's a simple call to log a fault – passing the name of the service provider and the service, description and severity of the fault, and an exception:

ServiceProviderErrorHandler.SubmitFault("ErroringService", "LogHandledException", "Caught exception", FaultSeverity.Error, ex);

To register the ServiceProviderErrorHandler to catch any unhandled exceptions that occur just requires a behaviour extension in the WCF service configuration:

<system.serviceModel>

</service>

</services>

<serviceProviderBehavior/>

</behavior>

</serviceBehaviors>

</behaviors>

<extensions>

<behaviorExtensions>

</behaviorExtensions>

</extensions>

</system.serviceModel>

Add this to all your WCF service providers and any exceptions will be logged and can be shown, filtered and subscribed to in the normal way.

ESB Guidance Demonstration: “TriathlonResults”

EltonStoneman — Sat, 25 Oct 2008 12:10:16 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

At the SBUG meeting last week, my session on "ESB Guidance: A Real-World Implementation" was meant to end with a demonstration, but we ran out of time - and in any case what I'd intended to show was probably a bit ambitious, with plenty of this-is-bound-to-go-wrong points.

But I've spent some time making it more solid and the code is available now on MSDN Code Gallery: ESB Guidance 1.0 Demonstration: TriathlonResults, if you want to have a look. You'll need an environment with BizTalk 2006 R2 and ESB Guidance 1.0 set up to run it, but I'm looking at putting together a Webcast to give a walkthrough.

Overview

The demonstration involves a set of systems which each have custom integrations to a central system, and shows two SOA approaches for integrating them with BizTalk and ESB Guidance. The first approach is a partial migration, where the client systems are unchanged, but the central system picks up messages directed through ESBG. The second is a "full" SOA migration, where the clients are changed to integrate directly with ESBG.

For the sake of an interesting demo, the systems are contrived to be unusual. They represent different systems for recording an athlete's time in a sector of a triathlon – each having a different UI and a different integration approach. The first sector - the swim - is recorded from a console app:

The second – the bike – from a WinForms app:

And the third – the run – from an Excel 2003 workbook with some VBA script:

The integrations add results to a central database, which has a particularly poor web front-end:

Pre-requisites

Windows Server 2003 with IIS & UDDI Services installed; SQL Server 2005; BizTalk Server 2006 R2; ESB Guidance 1.0.

The sample expects everything to live on localhost, and uses a SQL Server login so you need to have mixed authentication and named pipes enabled in your SQL Server instance.

Installation

Two steps after downloading the code – build and deploy the TriathlonResults.Phase1 solution (you'll need to modify the BizTalk projects to point to your own management database), then run the Deploy.cmd script (it'll ask for the name of your SQL Server – just use "." for a local un-named instance).

This will create:

two SQL databases – TriathlonResults and TriathlonStaging;
a SQL login – TriathlonResults;
a BizTalk application - TriathlonResults;
two IIS virtual directories – TriathlonResults.Web and TriathlonResults.Central.

In the Shortcuts folder under the solution root you'll have links to the various client apps, and to the website which shows the full results from the central system.

Phase 0

This is the starting point, with each system integrating to the central results service in a custom way:

Console app: receives user input and outputs as a delimited flat file; a central console app runs a FileSystemWatcher over the expected location, parses the flat file and inserts the record to the central database;
WinForms app: receives user input and sends the sector result as a Web service call to the central service, which inserts the record to the central database;
Excel workbook: receives user input and inserts the result as a record in a staging database; a trigger on the staging table retrieves the new record and inserts it to the central database.

To see this, run SetupPhase0.cmd and input some results. Usage of the client apps should be fairly straightforward – choose Athlete id=1 and Race id=1 to use known reference data, and refresh the web page for the first race after each input. You should see the sector times displayed after you enter them.

Phase 1

This is the first SOA approach, showing an option for partial migration. Here the central result-recording Web service has been exposed as a service through ESBG, and the clients all use the central service. The WinForms client has been changed to invoke the ESBG call directly, but the other systems are unchanged and a BizTalk app picks up their output and submits it to the ESB:

Console app: flat file output is now monitored by a BizTalk FILE Receive Location. The pipeline for the location parses the flat file into a known schema, and adds the itinerary details as context properties;
WinForms app: uses a typed Service Request class to submit messages to ESBG directly. This is a proxy class which deals with wrapping the message in an ESBG itinerary, and submitting it to the on-ramp;
Excel workbook: the trigger on the staging database is disabled and replaced with a SQL Receive Location which polls the staging table for unprocessed records. The pipeline adds itinerary details to the context;
TriathlonResults BizTalk app: for the FILE and SQL Receive Locations, the BizTalk app has custom orchestrations which map incoming messages to the contract for the Web service, and submit the request. The send port DynamicRequestResponse subscribes to any pre-formed itinerary message, so this picks up the message from the WinForms app, which doesn't require any specific workflow.

To use, close down any client apps you have running, run SetupPhase1.cmd, open the clients and input some results. The command clears down the results DB, so you should start with an empty results page on the website. As you use the clients you can confirm they're using ESBG by checking HAT. You'll probably also notice that the WinForms app responds more slowly when you submit a result.

Phase 2

This is a full SOA migration, where the consumers are aware of the mechanism for requesting services, unlike the Phase 1 approach where this was abstracted away from the legacy apps. All client apps are changed here to invoke the ESBG service request directly:

Console app: now uses the typed Service Request used by the WinForms app to build the ESBG message and submit it. Flat file no longer generated;
WinForms app: unchanged from Phase 1;
Excel Workbook: the typed Service Request is registered as a COM-callable Type Library and referenced from the Workbook. The VBA instantiates, populates and submits the ESBG message. Staging database no longer used;
TriathlonResults BizTalk app: the SQL and FILE receive locations are no longer used, all incoming messages are of the expected itinerary type and are all dealt with by the DynamicRequestResponse port.

To use, close down any client apps you have running, run SetupPhase2.cmd, open the clients and input some results. Again, you should start with an empty results page on the website and can use HAT to confirm messages are going through BizTalk. You'll notice now that all the apps are responding more slowly when you submit a result.

Notes

The Phase 1 approach is a pragmatic one, realising some of the benefits expected in SOA at the cost of others. We have reuse of loosely-coupled services, a centralised discoverable service repository, and centralised message flow. We don't have a common communication mechanism and we haven't got away from bespoke formats and protocols. In some environments this may be as far as the migration goes, if service consumers can't be modified. It has the benefit of being transparent to consumers, but with bespoke mapping and configuration for each consumer it will have the largest custom codebase – taking more effort to develop and maintain.

Phase 2 gives us the benefits of Phase 1, plus we are now using a single entry point to the ESB and consumers are submitting messages of known types which can be verified against the service contract schemas held in BizTalk. This particular implementation sees all the apps using a .NET component to abstract the work of creating the itinerary. This means consumers need no knowledge of BizTalk or ESB Guidance, but has the complication of distributing and maintaining that assembly. Consumers could use any approach to build their requests, provided they can understand XML and SOAP.