WCF

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.

Applying WCF Message Formatters Using Configuration

EltonStoneman — Sun, 05 Apr 2009 03:15:09 GMT

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

The WCF message formatter interfaces IClientMessageFormatter and IDispatchMessageFormatter let you intercept WCF messages on the client or service side at the point of serialization and deserialization. They're useful injection points as they give you access to the input or output parameter values of the service call, and to the incoming or outgoing WCF Message object. The formatters allow you to inspect or modify the message content or headers, using the call parameters to drive your logic.

Formatters need to be applied as operation behaviors, so there's no direct way to add them via binding configurations – typically they're added programmatically to the client channel, or to the service as attributes on the operation contract. But if your requirements are to add the same formatter to every operation and you want the flexibility of the configuration model, you can add formatters by piggybacking onto other behaviors which can be specified in configuration – IEndpointBehavior on the client and IServiceBehavior on the service:

(more detail on the data signature project in a future post).

Client Side

DataSignatureOperationBehavior.ApplyClientBehavior adds a DataSignatureClientFormatter to a single client operation:

public void ApplyClientBehavior(OperationDescription operationDescription, ClientOperation clientOperation)

{

DataSignatureClientFormatter formatter = new DataSignatureClientFormatter();

formatter.OrginalFormatter = clientOperation.Formatter;

clientOperation.Formatter = formatter;

}

Adding the formatter to one operation cannot be specified in client-side configuration. However the DataSignatureOperationBehavior can be added to every client operation in an endpoint using IEndpointBehavior.ApplyClientBehavior. DataSignatureEndpointBehavior adds the client formatter to every operation, by using the existing operation behavior:

public void ApplyClientBehavior(ServiceEndpoint endpoint, ClientRuntime clientRuntime)

{

foreach (OperationDescription operation in endpoint.Contract.Operations)

{

operation.Behaviors.Add(new DataSignatureOperationBehavior());

}

The endpoint behavior is exposed in the client configuration mode by extending BehaviorExtensionElement, so the DataSignatureFormatter can be added to every operation in an endpoint by configuring the DataSignatureEndpointBehavior:

<endpoint address="http://localhost/x.y.z.svc"

binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_ICustomerService"

behaviorConfiguration="dataSignatureBehavior"

contract="CustomerService.ICustomerService" name="BasicHttpBinding_ICustomerService" />

</client>

</behavior>

</endpointBehaviors>

</behaviors>

<add

name="dataSignatureBehavior"

type="Sixeyed.OptimisticLockingSample.ServiceModel.Behaviors.DataSignatureEndpointBehavior…/>

</behaviorExtensions>

</extensions>

Service Side

The service stack is the parallel of the client side – DataSignatureDispatchFormatter is added via an operation behavior using DataSignatureOperationBehavior.ApplyDispatchBehavior:

public void ApplyDispatchBehavior(OperationDescription operationDescription, DispatchOperation dispatchOperation)

{

DataSignatureDispatchFormatter formatter = new DataSignatureDispatchFormatter();

formatter.OrginalFormatter = dispatchOperation.Formatter;

dispatchOperation.Formatter = formatter;

}

Again this behavior is not available in the service configuration model, but it can be added to every operation in the service using IServiceBehavior.ApplyDispatchBehavior, as is done in DataSignatureServiceBehavior:

public void ApplyDispatchBehavior(ServiceDescription serviceDescription, System.ServiceModel.ServiceHostBase serviceHostBase)

{

foreach (ServiceEndpoint endpoint in serviceDescription.Endpoints)

{

foreach (OperationDescription operation in endpoint.Contract.Operations)

{

operation.Behaviors.Add(new DataSignatureOperationBehavior());

}

This behavior also extends BehaviorExtensionElement so it can be configured, adding the dispatch formatter will be added to every operation in the service:

<service behaviorConfiguration="dataSignatureBehavior"

name="Sixeyed.OptimisticLockingSample.Services.CustomerService">

<endpoint address="" binding="basicHttpBinding" contract="Sixeyed.OptimisticLockingSample.Services.ICustomerService"

bindingNamespace="http://Sixeyed.OptimisticLockingSample/2009"/>

</service>

</services>

</behavior>

</serviceBehaviors>

</behaviors>

<add

name="dataSignatureBehavior"

type="Sixeyed.OptimisticLockingSample.ServiceModel.Behaviors.DataSignatureServiceBehavior…/>

</behaviorExtensions>

</extensions>

Additionally, the DataSignatureOperationBehavior extends Attribute, so for finer-grained control the declarative approach is available using the same stack.

Accessing Extended Data from IExtensibleDataObject

EltonStoneman — Fri, 03 Apr 2009 23:51:08 GMT

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

DataContract classes in WCF can be declared as implementing IExtensibleDataObject to provide in-built support for schema versioning. Any data contracts created through svcutil or Add Service Reference implement the interface, and it's good practice to implement it for any custom DataContract classes you write. On deserializing, elements which are not declared in the data contract are extracted by the DataContractSerializer and added to the ExtensionDataObject property, so unexpected data is not lost (see Vagif Abilov's blog post on backwards compatibility with IExtensibleDataObject).

Internally, the ExtensionDataMember holds a convoluted key-value collection of the unrecognised data members. If you want to inspect the contents of the collection it's a fiddly process as the members are non-public, and the types and interfaces of the members (ExtensionDataMember and IDataNode) are also non-public. The code below allows you to extract the value of an ExtensionDataMember given its name:

private object GetExtensionDataMemberValue(IExtensibleDataObject extensibleObject, string dataMemberName)

{

object innerValue = null;

PropertyInfo membersProperty = typeof(ExtensionDataObject).GetProperty("Members", BindingFlags.NonPublic | BindingFlags.Instance);

IList members = (IList)membersProperty.GetValue(extensibleObject.ExtensionData, null);

foreach (object member in members)

{

PropertyInfo nameProperty = member.GetType().GetProperty("Name", BindingFlags.NonPublic | BindingFlags.Instance);

string name = (string) nameProperty.GetValue(member, null);

if (name == dataMemberName)

{

PropertyInfo valueProperty = member.GetType().GetProperty("Value", BindingFlags.NonPublic | BindingFlags.Instance);

object value = valueProperty.GetValue(member, null);

PropertyInfo innerValueProperty = value.GetType().GetProperty("Value", BindingFlags.Public | BindingFlags.Instance);

innerValue = innerValueProperty.GetValue(value, null);

break;

}

return innerValue;

}

Obviously this is fragile and isn't appropriate for production solutions, but it can be useful for unit testing or debugging WCF calls, or when you want to confirm the effects of having data contracts which are out of sync between the service and the consumer. Similar code could be used to get the count of extended data members to identify if the DataContract schema is not the correct version, and interestingly, the value and innerValue properties are writeable, so you could update the contents of the unrecognised members.

Using WCF-Custom Bindings in Dynamic Ports

EltonStoneman — Fri, 06 Mar 2009 23:38:49 GMT

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

BizTalk 2006 R2 ships with WCF adapters and pre-configured settings for common bindings - basicHttp and wsHttp being typically used for SOAP messaging. With a static port you can use the WCF-Custom adapter, select an existing binding and configure it further in the UI, with the full set of binding options available to you:

Here I'm using basicHttp, but I've configured the maxReceivedMessageSize, sendTimeout and transferMode settings to allow us to call long-running WCF services which return large responses.

In a dynamic port, you're limited to the settings you can configure, as the WCF Adapter Property Schema doesn't contain the full set of binding properties. You can set the sendTimeout and maxReceivedMessageSize on an outgoing message using code:

port(Microsoft.XLANGs.BaseTypes.TransportType) = "WCF-BasicHttp";

requestMessage(WCF.MaxReceivedMessageSize) = 104857600;

requestMessage(WCF.SendTimeout) = "00:10:00";

- but there's no way to access less common properties like transferMode if you're using this approach. Originally this is how we were configuring our outgoing messages, using SSO to store the values used for the binding properties (see Receiving large WCF response messages in ESB Guidance), but we soon ran into an issue with one of the BizTalk servers running out of memory when attempting to process a large WCF response message:

System.InsufficientMemoryException: Failed to allocate a managed memory buffer of 104857600 bytes. The amount of available memory may be low. ---> System.OutOfMemoryException: Exception of type 'System.OutOfMemoryException' was thrown.

at System.ServiceModel.Diagnostics.Utility.AllocateByteArray(Int32 size)

For basicHttp, the transferMode setting allows you to specify that messages should be streamed (one way or both ways), or buffered - the default is buffered, so when we receive the response message, although it will be streamed in the BizTalk stack, it is completely loaded into memory by the WCF stack. Note that WCF is trying to allocate the full value specified in maxReceivedMessageSize – 100 Mb – even though we've set this as a practical maximum, and the actual incoming message was half that size.

To remedy it, I've switched to using the WCF-Custom transport, and specifying basicHttp with my additional settings in the BindingConfiguration property:

port(Microsoft.XLANGs.BaseTypes.TransportType) = "WCF-Custom";

requestMessage(WCF.BindingType) = "basicHttpBinding";

requestMessage(WCF.BindingConfiguration) = "<binding name=\"basicHttpBinding\" sendTimeout=\"00:10:00\" maxReceivedMessageSize=\"104857600\" />";

The BindingType needs to be specified in addition to the configuration. For the BindingConfiguration value, the Properties page for a static WCF-Custom port allows you to export the settings, so you can configure it in the UI and then save the XML representation, rather than coding it all by hand.

By shifting the BindingConfiguration value to the SSO config store, we'll have the full range of WCF configuration available to change at run-time, so a switch to using wsHttp or netTcp bindings is just a setting change using the SSO Config Tool, and a change to the endpoint address (which we configure in UDDI in this case). Originally I wanted finer control over what could be configured, so we could limit changes to a known set of properties. But having tried this approach I prefer it – it means switching bindings and adding or changing any settings can easily be done without modifying the solution – and I'll be recommending it as best practice.

Using the WCF SQL Adapter in .NET: Executing SQL Statements

EltonStoneman — Thu, 05 Mar 2009 01:21:35 GMT

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

Following on from my post on Using the WCF SQL Adapter in .NET: Calling Stored Procedures (see that post for download and installation instructions for the WCF LOB adapter pack), this one looks at using the adapter to execute SQL statements on database objects.

Walkthrough: Executing SQL Statements

Add Adapter Service Reference generates separate entity and client classes for each table you select, and separate request and response classes for each table operation. To generate proxies for executing SQL statements against a table, choose the operations from the Tables view of the hierarchy:

Selecting the Insert and Select operations against the BikeTypes table will generate the following class structure:

The client for connecting to SQL Server is a standard WCF client class, inheriting from ClientBase and specifying the ServiceContract as its channel – in this case the interface is TableOp_dbo_BikeTypes which has operation contracts representing the Insert and Select statements. The entity representing the database table implements IExtensibleDataObject and provides DataMember-flagged properties for each table column; an array of entities is used as the input for the Insert operation, and the return for the Select operation (wrapping the underlying use of generated Request and Response classes).

The Request and Response classes are flagged with MessageContract attributes. Message contracts are less commonly seen than DataContract and ServiceContract, but they allow you finer control over the messages sent and received by the adapter, including the ability to specify whether data is to be serialized in the header or body of the message (see Using Message Contracts). In the generated classes, MessageContract is used to specify the wrapper name and namespace, which puts the message payload within a defined element in the SOAP body. The following attribute:

[System.ServiceModel.MessageContractAttribute(WrapperName="Select", WrapperNamespace="http://schemas.microsoft.com/Sql/2008/05/TableOp/dbo/BikeTypes", IsWrapped=true)]

- generates a SOAP message for the SelectRequest class which looks like this:

<s:Envelope xmlns:a="http://www.w3.org/2005/08/addressing" xmlns:s="http://www.w3.org/2003/05/soap-envelope">

<s:Header>

<a:Action s:mustUnderstand="1">TableOp/Select/dbo/BikeTypes</a:Action>

<a:MessageID>urn:uuid:9a5fe359-e988-4504-96a9-b9b721d00502</a:MessageID>

<a:ReplyTo>

<a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>

</a:ReplyTo>

</s:Header>

<s:Body>

<Query>WHERE BikeTypeCode LIKE '%R%'</Query>

</Select>

</s:Body>

</s:Envelope>

Note that the SOAP action is the Node Id for the operation from Add Adapter Service Reference. The request message contains Columns and Query elements, which are used in the call to refine the size and content of the resultset. In code you specify the Columns property with "*" to return all, or a comma-separated list of column names (which should be listed in the same order as defined in the table). Query can be null, empty or contain a WHERE clause to restrict the results:

TableOp_dbo_BikeTypesClient client = new TableOp_dbo_BikeTypesClient();

client.Open();

BikeTypes[] allBikeTypes = client.Select("*", null);

BikeTypes[] bikeTypeDescriptions = client.Select("BikeTypeDescription", string.Empty);

BikeTypes[] likeRBikeTypes = client.Select("*", "WHERE BikeTypeCode LIKE '%R%'");

A populated Query property will limit the number of items returned. A populated Columns property will limit the number of populated elements in the response, so the typed object will have null values for any unmapped columns.

For the insert, you pass an array of populated entities to the call:

List<BikeTypes> bikeTypes = new List<BikeTypes>();

bikeTypes.Add(new BikeTypes());

bikeTypes[0].BikeTypeCode = "NEW";

bikeTypes[0].BikeTypeDescription = "New Type";

TableOp_dbo_BikeTypesClient client = new TableOp_dbo_BikeTypesClient();

client.Open();

client.Insert(bikeTypes.ToArray());

If you want to write identity values for tables which have an identity column, you can specify AllowIdentityInsert in the binding configuration. Otherwise, any specified columns have the value from the entity inserted; null values have NULL inserted. The return contains an array of long values containing the identity of the inserted rows – unless the table does not have an identity column, in which case the return is null.

Similarly the adapter can generate request and response classes for Update and Delete statements, which follow the same pattern. The generated stack has the same benefits as with the stored procedure calls – the code is very light and it uses the standard WCF stack, so if you'd rather generate or hand-craft your own connections, that's a definite option. I'll explore it in a later post.

Using the WCF SQL Adapter in .NET: Calling Stored Procedures

EltonStoneman — Tue, 03 Mar 2009 00:42:45 GMT

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

The Adapter Pack 2.0 for BizTalk has been released in public beta recently, and among the WCF Line Of Business adapters it contains the WCF SQL adapter. This exposes SQL Server connections as WCF service endpoints, and lets you connect to a SQL Server source using the standard ServiceModel stack. The adapter pack will be released under the BizTalk brand, but the adapters themselves are not limited to BizTalk – the WCF SQL adapter can be used natively in .NET code.

This is a brief walkthrough covering the SQL Adapter for executing stored procedures, and I'll be covering SQL statements in a subsequent post.

Installation

Installation of the Adapter Pack is straightforward – you'll need .NET 3.5 Service Pack 1 with the latest hotfixes applied, and you'll need to install the WCF LOB Adapter SDK and then the BizTalk Adapter Pack 2.0 Evaluation (the beta version is limited to 120-day use). Note, you do not need to have BizTalk installed, and the tooling to support the WCF LOB adapters runs under Visual Studio 2008 as well as 2005. Help files for all the adapters are included, and although in pre-release form they are detailed and thorough.

Walkthrough: Consuming a Stored Procedure

The Adapter Pack adds a new context menu to code projects in Visual Studio – Add Adapter Service Reference. Run this and you're given a generic form for configuring your WCF LOB adapter. Choose sqlBinding to set up a WCF SQL connection:

Click Configure and you specify the connection configuration that will be used to build the binding. In the case of the WCF SQL adapter, you need to specify:

Client Credential Type (Windows for integrated authentication);
Server (database server name);
Instance (SQL instance name, if configured);
Initial catalog (the database to connect to).

This will build you a URI of the form: mssql://<server>/<instance>/<initialCatalog>? – with the ending question mark used to separate the core connection details from any configuration options.

Click Connect and you have the option to generate a Client binding, for making outbound requests to SQL Server (executing SQL statements, stored procedures etc.), or a Service binding which will react to inbound calls from SQL Server (for Query Notification or polling). Choose Client and the category view will be populated with a hierarchy of database objects which can be generated as WCF client proxies:

Generated Code

For stored procedure calls, the adapter can create generic proxies for weakly-typed calls returning populated DataSets, or strongly-typed calls which will generate entities representing the return from the call. In this case I've selected a Strongly-Typed Stored Procedure called GetManufacturer; add the selection and with the default options the adapter generates two items:

App.config – containing the WCF binding configuration;
SqlAdapterBindingClient.cs – containing the generated entity types and proxy classes.

The full binding configuration for the SQL adapter looks like this:

<system.serviceModel>

<binding name="SqlAdapterBinding" closeTimeout="00:01:00" openTimeout="00:01:00"

receiveTimeout="00:10:00" sendTimeout="00:01:00" maxConnectionPoolSize="100"

encrypt="false" workstationId="" useAmbientTransaction="true"

batchSize="20" polledDataAvailableStatement="" pollingStatement=""

pollingIntervalInSeconds="30" pollWhileDataFound="false" notificationStatement=""

notifyOnListenerStart="true" enableBizTalkCompatibilityMode="true"

chunkSize="4194304" inboundOperationType="Polling" useDatabaseNameInXsdNamespace="false"

allowIdentityInsert="false" enablePerformanceCounters="false"

xmlStoredProcedureRootNodeName="" xmlStoredProcedureRootNodeNamespace="" />

</sqlBinding>

</bindings>

<endpoint address="mssql://x/y/z?" binding="sqlBinding"

bindingConfiguration="SqlAdapterBinding" contract="TypedProcedures_dbo"

name="SqlAdapterBinding_TypedProcedures_dbo" />

</client>

</system.serviceModel>

- note that the binding contains some familiar WCF settings (sendTimeout, receiveTimeout), but the majority are SQL Server specific connection options. The client element specifies the contract as TypedProcedures_dbo, the ServiceContract interface generated by the adapter, which has a single OperationContract defined:

GetManufacturerResponse GetManufacturer(GetManufacturerRequest request);

The proxy code for the client is all generated, so to invoke the stored procedure in your own code it's a familiar case of instantiating the client and calling the service, and of course you have full IntelliSense on the entity representing the resultset:

It's the content of the generated code that's interesting. The service, request, response and entity objects here are contained in 166 lines of generated code. The entity object is just a plain DTO-style class which implements IExtensibleDataObject to allow access to any returned data that hasn't been mapped, and has a DataContract attribute with the schema name representing the stored procedure. The mapping between the entity properties and the returned columns is done with standard System.Runtime.Serialization attributes, so the ManufacturerId column is represented as:

[System.Runtime.Serialization.DataMemberAttribute()]

public System.Nullable<short> ManufacturerId {

get {

return this.ManufacturerIdField;

}

set {

this.ManufacturerIdField = value;

}

- note that this is an optional field in the database table, so it's generated as nullable in the entity. No other flags or code are used to map data, so the WCF SQL adapter is effectively deserializing the resultset from the stored procedure call straight into the DataContract.

The generated code works well and is cleanly produced, but it has a few quirks you may not be happy with. A typed client class is generated for each individual procedure, whereas you might want them grouped into a single class which represents the full suite; and the class names are a bit cumbersome ("StoredProcedureResultSet0", "TypedProcedures_dboClient"). However, the code needed to actually connect to SQL through WCF and map the response is so simple that it's a straightforward task to generate your own code from custom templates.

Potential Usage

After an initial look, the WCF SQL adapter seems to be an attractive option for generating and powering the data access layer of a .NET application, entirely apart from its primary purpose as a BizTalk adapter. It repositions data access as a service call and uses the standard WCF mechanisms of ServiceContract and DataContract for information exchange. Assuming other data providers follow suit, or other WCF-database adapters follow from the community, it's a nice way of isolating your application from the physical database, so swapping to MySQL or Oracle could become a simple matter of changing your WCF binding.

It'll be interesting to see the licensing of the WCF LOB adapters from Microsoft. Currently the availability of a comprehensive suite of adapters is being positioned as one of the attractions of BizTalk as the Integration Server, compared to WF+WCF+Dublin as the Application Server. With the WCF SQL adapter there's a lot of potential take-up as a simpler alternative to the ADO.NET Entity Framework, so if it requires a BizTalk license, there will be room for an open source alternative.

Receiving large WCF response messages in ESB Guidance

EltonStoneman — Wed, 25 Feb 2009 23:51:53 GMT

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

WCF bindings provide the MaxReceivedMessageSize property, which lets you block any incoming messages on the client side over a given size (defaulting to 64Kb). If you're using message-based itinerary processing with ESB Guidance, when a WCF service returns a message larger than this default, you'll get a System.ServiceModel.QuotaExceededException and the response message will be suspended:

System.ServiceModel.CommunicationException: The maximum message size quota for incoming messages (65536) has been exceeded. To increase the quota, use the MaxReceivedMessageSize property on the appropriate binding element. ---> System.ServiceModel.QuotaExceededException: The maximum message size quota for incoming messages (65536) has been exceeded. To increase the quota, use the MaxReceivedMessageSize property on the appropriate binding element.

Setting the MaxReceivedMessageSize property is straightforward in a configured WCF port, but in ESB Guidance the port is configured dynamically and there's no straightforward way to interrupt it and add your own WCF bindings. To give us access to the message and the port, we replaced the "DynamicSendResponse" port used in the GlobalBank.ESB sample with a simple orchestration.

The orchestration has a direct-bound receive port filtering on the usual properties:

(Microsoft.Practices.ESB.Itinerary.Schemas.ServiceName == "DynamicResolutionSolicitResp") &&

(Microsoft.Practices.ESB.Itinerary.Schemas.ServiceState == "Pending") &&

(Microsoft.Practices.ESB.Itinerary.Schemas.ServiceType == "Messaging")

- it then builds the outgoing message for the service, and configures the dynamic send/receive port. At this point the message has all the properties you need configured by ESB (via the resolver pipeline component in the previous itinerary steps), so you can extract them to configure the port, and add any WCF binding configuration you need.

We store the configuration in the Enterprise Single Sign-On application config store using SSO Config Tool, so the expression to build the outgoing message and increase the received message size looks like this –

//setup port from context properties:

sptServiceProvider(Microsoft.XLANGs.BaseTypes.Address) = ServiceProviderRequest(BTS.OutboundTransportLocation);

sptServiceProvider(Microsoft.XLANGs.BaseTypes.TransportType) = ServiceProviderRequest(BTS.OutboundTransportType);

//set message size from config:

maxReceivedMessageSize = x.y.z.Configuration.X_Y_Z_Config.WCFMaxReceivedMessageSize;

ServiceProviderRequest(WCF.MaxReceivedMessageSize) = maxReceivedMessageSize;

Microsoft.Practices.ESB.Adapter.AdapterMgr.SetMsgProperty(ServiceProviderRequest, typeof(WCF.MaxReceivedMessageSize), maxReceivedMessageSize);

//set timeout from config:

sendTimeout = x.y.z.Configuration.X_Y_Z_Config.WCFSendTimeout;

ServiceProviderRequest(WCF.SendTimeout) = sendTimeout;

Note that the WCF config is set on the message, not on the port. We're also setting timeout values here. When you're dealing with large messages, you may get operation timeouts as the default binding config from BizTalk is set to a pessimistic 1 minute. Value WCF.SendTimeout specifies how long the BizTalk client waits for a response, and WCF.ReceiveTimeout how long the BizTalk client allows for the reception of a request. If your WCF service is hosted in IIS and is long-running, you may also have an issue with IIS controlling execution times. See: Why changing SendTimeout does not help for hosted WCF services.

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.

T4 template to generate Wix scripts to generate WCF MSIs in MSBuild

EltonStoneman — Thu, 04 Sep 2008 19:55:11 GMT

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

Snappy title. We have a project which contains lots of WCF Service projects, and we want to generate MSIs so we can deploy them to IIS. The gaps between the projects are minimal as they all use the same structure, so instead of having separate Setup or Wix files in each of the solutions, generating the WXS files on the fly was an option.

The installer steps we wanted were reasonably simple:

install WCF artifacts to the chosen directory (.svc and web.config files)
install WCF binaries to the chosen directory\bin
install dependencies to the GAC
create a virtual directory in IIS pointing to the install directory

The only UI we particularly needed was the choice of install directory, so the Wix for this fits into a fairly straightforward T4 template:

<#@ template language="C#" #>

<#@ output extension=".xml" #>

<#@ assembly name="System.dll" #>

<#@ import namespace="System.IO" #>

<#@ import namespace="System.Security.Cryptography" #>

<#@ import namespace="System.Text" #>

<?xml version="1.0" encoding="UTF-8"?>

<Product Id="<#= this.GetProductId() #>"

Name="<#= ServiceName #>"

Language="1033"

Version="<#= VersionNumber #>"

Manufacturer="Company"

UpgradeCode="<#= this.GetUpgradeCode() #>">

<Media Id="1" Cabinet="<#= ServiceName #>.Install.cab" EmbedCab="yes" />

<# foreach (string filePath in this.WcfArtifacts.Split(';'))

{

this.AddFile(filePath);

}#>

</Component>

<# int index = 0;

foreach (string assemblyPath in this.WcfDependencies.Split(';'))

{#>

<Component Id="GACComponent_<#= index++ #>" Guid="<#= this.GetNewGuid() #>" SharedDllRefCount="yes">

<# this.AddAssemblyToGAC(assemblyPath); #>

</Component>

<#}#>

<# this.AddAssembly(this.WcfAssembly); #>

</Component>

</Directory>

<iis:WebVirtualDir Id="WcfVirtualDir" Alias="<#= ServiceName.TrimEnd(".Wcf".ToCharArray()) #>" Directory="INSTALLLOCATION" WebSite="DefaultWebSite">

<iis:WebApplication Id="WcfApplication" Name="<#= ServiceName #>" />

</iis:WebVirtualDir>

</Component>

</Directory>

<iis:WebSite Id="DefaultWebSite" Description="Default Web Site">

<iis:WebAddress Id="AllUnassigned" Port="80" />

</iis:WebSite>

<Feature Id="ProductFeature" Title="<#= ServiceName #>" Level="1">

<# int i = 0;

foreach (string assemblyPath in this.WcfDependencies.Split(';'))

{#>

<# } #>

</Feature>

</Product>

</Wix>

<#+

private string ServiceName

{ get{ return "$(ProjectName).$(ProjectFilter)"; }}

private string VersionNumber

{ get{ return "$(Version)"; }}

private string WcfArtifacts

{ get{ return @"@(WcfArtifacts)"; }}

private string WcfAssembly

{ get{ return @"@(WcfAssembly)"; }}

private string WcfDependencies

{ get{ return @"@(WcfDependencies)"; }}

…

- the full template is here: WCF Service Wix template.

A couple of interesting things here – the Guids are generated from the name of the elements (see Generating Deterministic Guids), so multiple versions will have the same Guid and will operate as updates, provided the name of the service doesn't change; the tags for MSBuild properties in the template get resolved using the ExecuteT4Template MSBuild task; the GACd assemblies flag themselves as SharedDllRefCount so if you uninstall this package, the files will be left in the GAC if any other packages use them, but removed if this is the only package that uses them.

Another custom task is needed to resolve the dependencies of the WCF assembly (sample version here: MSBuild ResolveDependencies task), and the MSBuild snippet to run it together with the Wix commands looks like this:

<ResolveDependencies AssemblyList="@(WcfAssembly)"

Filter="$(CompanyName).$(ProductName)">

</ResolveDependencies>

</Target>

<ExecuteT4Template ToolPath="$(MSBuildProjectDirectory)\$(BuildBinDir)"

TemplatePath="$(TemplateRoot)\Services.Wcf.wxs.tt"

OutputPath="$(ArtefactWixDir)\$(ProductName).$(ProjectName).Wcf.wxs">

</ExecuteT4Template>

</Target>

- we store all the intermediate files (the T4 template with resolved property values, WXS and WIXOBJ files) to help with debugging.

Flattening WSDL from WCF Services

EltonStoneman — Wed, 30 Jul 2008 17:23:15 GMT

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

If you're hosting WCF services in IIS and try accessing the WSDL using ServiceDescriptionImporter.Import, you'll get an error saying Unable to import binding BasicHttpBinding_IXyzService…

WCF separates out its schemas into logical components, which ServiceDescriptionImporter and other clients (including the ESBSimpleSamples ServiceClient generator) can't work with, as they're expecting a single flat WSDL.

Christian Weyer from Thinktecture has a solution here: Improving WCF Interoperability: Flattening your WSDL. If you download and build his sample project, copy Thinktecture.ServiceModel.Extensions.Description.dll to your service bin folder and amend your .svc description to use the Thinktecture factory:

<% @ServiceHost Language=C# Service="Xyz.XyzService" Factory="Thinktecture.ServiceModel.Extensions.Description.FlatWsdlServiceHostFactory " %>

- this will return a flattened WSDL, so tools expecting one file will work correctly.