Paolo Pialorsi - Bridge The Gap! : SOA

Handling custom SOAP headers via WCF Behaviors

paolopia — Mon, 25 Feb 2008 10:13:14 GMT

A few days ago a customer of mine asked me how to define a WCF behavior to add a custom SOAP Header to sent/received messages.

The solution is not so far from what I've shown in the previous "Writing a WCF Message Inspector" post. In fact one way of working is to define a custom message inspector that writes/reads the custom SOAP Header.

So first of all we need a SOAP Header. Here is the code to define a custom header to handle a random key (as a Guid) injected in every request sent from the consumer to the service:

public class CustomHeader : MessageHeader
{
private String _key;

    public String Key
    {
        get
        {
            return (this._key);
        }
    }

    public CustomHeader(String key)
    {
        this._key = key;
    }

    public override string Name
    {
        get { return (CustomHeaderNames.CustomHeaderName); }
    }

    public override string Namespace
    {
        get { return (CustomHeaderNames.CustomHeaderNamespace); }
    }

    protected override void OnWriteHeaderContents(System.Xml.XmlDictionaryWriter writer, MessageVersion messageVersion)
    {
        // Write the content of the header directly using the XmlDictionaryWriter
        writer.WriteElementString(CustomHeaderNames.KeyName, this.Key);
    }

    public static CustomHeader ReadHeader(XmlDictionaryReader reader)
    {
        // Read the header content (key) using the XmlDictionaryReader
        if (reader.ReadToDescendant(CustomHeaderNames.KeyName, CustomHeaderNames.CustomHeaderNamespace))
        {
            String key = reader.ReadElementString();
            return (new CustomHeader(key));
        }
        else
        {
            return null;
        }
    }
}

public static class CustomHeaderNames
{
public const String CustomHeaderName = "CustomHeader";

public const String KeyName = "Key";

public const String CustomHeaderNamespace = "http://schemas.devleap.com/CustomHeader";

}

As you can see it is a type inheriting from MessageHeader class. Notice the OnWriteHeaderContents override, which is invoked by WCF infrastructure to serialize the SOAP Header, and the ReadHeader static method that we will use later.

Such a SOAP Header need to be added by the consumer and read by the service. To do this we need a MessageInspector like the following one:

public class CustomMessageInspector : IDispatchMessageInspector, IClientMessageInspector
{
#region Message Inspector of the Service

    public object AfterReceiveRequest(ref Message request, IClientChannel channel, InstanceContext instanceContext)
    {
        // Look for my custom header in the request
        Int32 headerPosition = request.Headers.FindHeader(CustomHeaderNames.CustomHeaderName, CustomHeaderNames.CustomHeaderNamespace);

// Get an XmlDictionaryReader to read the header content
XmlDictionaryReader reader = request.Headers.GetReaderAtHeader(headerPosition);

// Read it through its static method ReadHeader
CustomHeader header = CustomHeader.ReadHeader(reader);

// Add the content of the header to the IncomingMessageProperties dictionary
OperationContext.Current.IncomingMessageProperties.Add("key", header.Key);

return null;
}

    public void BeforeSendReply(ref Message reply, object correlationState)
    {
    }

#endregion

#region Message Inspector of the Consumer

    public void AfterReceiveReply(ref Message reply, object correlationState)
    {
    }

    public object BeforeSendRequest(ref Message request, IClientChannel channel)
    {
        // Prepare the request message copy to be modified
        MessageBuffer buffer = request.CreateBufferedCopy(Int32.MaxValue);
        request = buffer.CreateMessage();

// Simulate to have a random Key generation process
request.Headers.Add(new CustomHeader(Guid.NewGuid().ToString()));

return null;
}

#endregion
}

As you can see from the code sample above, we use the IClientMessageInspector implementation to handle the addition of the header in the consumer-side code, while we use the IDispatchMessageInspector on the service side, to extract the header. It is interesting the FindHeader method of the MessageHeaders collection, as well as the method GetReaderAtHeader, provided by the same collection of SOAP Headers. The result of this last method is an XmlDictionaryReader that we use to read our custom header content, through the ReadHeader static method we've already introduced.

The service will be able to read the Key provided throught the custom SOAP header simply querying the IncomingMessageProperties dictionary:

OperationContext.Current.IncomingMessageProperties["key"]

Of course this custom MessageInspector needs to be plugged into the WCF pipeline using a custom behavior like the following one:

[AttributeUsage(AttributeTargets.Class)]
public class CustomBehavior : Attribute, IEndpointBehavior
{
#region IEndpointBehavior Members

    public void AddBindingParameters(ServiceEndpoint endpoint, System.ServiceModel.Channels.BindingParameterCollection bindingParameters)
    {
    }

    public void ApplyClientBehavior(ServiceEndpoint endpoint, System.ServiceModel.Dispatcher.ClientRuntime clientRuntime)
    {
        CustomMessageInspector inspector = new CustomMessageInspector();
        clientRuntime.MessageInspectors.Add(inspector);
    }

    public void ApplyDispatchBehavior(ServiceEndpoint endpoint, System.ServiceModel.Dispatcher.EndpointDispatcher endpointDispatcher)
    {
        ChannelDispatcher channelDispatcher = endpointDispatcher.ChannelDispatcher;
        if (channelDispatcher != null)
        {
            foreach (EndpointDispatcher ed in channelDispatcher.Endpoints)
            {
                CustomMessageInspector inspector = new CustomMessageInspector();
                ed.DispatchRuntime.MessageInspectors.Add(inspector);
            }
        }
    }

    public void Validate(ServiceEndpoint endpoint)
    {
    }

#endregion
}

We also need an ExtensionElement to configure the behavior:

public class CustomBehaviorExtensionElement : BehaviorExtensionElement
{
    protected override object CreateBehavior()
    {
        return new CustomBehavior();
    }

    public override Type BehaviorType
    {
        get
        {
            return typeof(CustomBehavior);
        }
    }
}

At last we can configure in the .config file of our service and consumer the behavior. Here is the service side configuration:

<system.serviceModel>

</behaviors>

</system.serviceModel>

And here is the configuration of the consumer-side:

<system.serviceModel>

</system.serviceModel>

That's all! Enjoy your custom SOAP header defining infrastructural protocols, but don't forget to check the wide range of WS-* specifications before inventing your own :-) ...

WCF Security Full Demo

paolopia — Sun, 16 Dec 2007 15:57:55 GMT

Here you can find the last version of a sample application showing many of the security features and configuration of WCF in the fields of security.
I've just updated it in order to release it during my last WebCast about WCF Security for MSDN Italy.

In this sample you can see (adding/removing endpoints and configuration elements from the config file):

Windows Authentication and Windows Authorization via transport level security on basicHttpBinding
Windows Authentication and Windows Authorization via message level security on wsHttpBinding
UsernamePasswordToken Authentication with ASP.NET Membership and ASP.NET Role Authorization via message level security on wsHttpBinding
UsernamePasswordToken Authentication with custom validator via message level security on wsHttpBinding
Authorization using a custom Authorization Policy
Impersonation using Windows credentials
Custom impersonation of custom Principal and Identity
Handling of multiple identities (one Primary plus others)
A quick and basic sample of interoperability with ASMX consumers using a custom UsernamePasswordToken over SSL, in the respect of WS-Security and WSS UsernameToken Profile 1.0 by Oasis, without using WSE

Enjoy and feel free to give me your feedbacks or further suggestions.

WCF Custom Authentication and Impersonation: demo source code

paolopia — Sun, 05 Feb 2006 22:36:00 GMT

Related to my last sample of custom authentication and impersonation within a WCF service, here is the sample code.
It works and compiles under GoLive WCF license. I hope you'll find it useful and interesting.

Italian version - Versione italiana

UPDATE: WinFx February CTP edition of this sample: coming soon ... sorry for the delay.

Distributed Transactions with Indigo and WS-AT

paolopia — Thu, 23 Jun 2005 00:13:00 GMT

This evening I played with Indigo and WS-AT, to see if it works, in order to use it in a project of a customer of mine.

First of all the good news: it works :-) as it did in PDC03 bits! Great job guys!
Second news: it's not so easy to manage all the stuff, but at least it works fine.

I developed two different services, working on a couple of SQL Server 2005 database.
One service is exposed using a net.tcp (netProfileTcpBinding) binding. The other is exposed using http (wsProfileBinding), self-hosted.

Both are used by a third party client, that covers the transactional work with a TransactionScope.

Here is a sample of one of the two transactional services:

namespace ServiceOne
{
[ServiceContract(
  FormatMode=ContractFormatMode.XmlFormatter,
  Namespace="http://schemas.devleap.com/Services/OrderService1",
  Style=ServiceOperationStyle.DocumentBare,
  Use=ServiceOperationBindingUse.Literal)]
[BindingRequirements(
  TransactionFlowRequirements = RequirementsMode.Require)]
public interface ITxServiceOne
{
  [OperationContract(
   Action="urn:saveOrder1")]
  Int32 SaveOrder(OrdersLibrary.Order order);
}

[ServiceBehavior(
  AllowConcurrentTransactions=true,
  TransactionIsolationLevel=IsolationLevel.ReadCommitted)]
public class TxServiceOne: ITxServiceOne
{
  [OperationBehaviorAttribute(
   AutoEnlistTransaction = true,
   AutoCompleteTransaction = true)]
  public int SaveOrder(OrdersLibrary.Order order)
  {
   OrdersLibrary.OrderBiz ob = new OrdersLibrary.OrderBiz();
   return (ob.SaveOrder(order));
  }
}
}

Take care of BindingRequirements and OperationBehavior attributes, respectively on the service contract and on the operation implementation.

Here is the service side configuration file:

<?xml version="1.0" encoding="utf-8" ?>
<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
<appSettings>
  <add key="SqlConnectionString" value="..."/>
</appSettings>
<system.serviceModel>
  <services>
   <service
    serviceType="ServiceOne.TxServiceOne, ServiceOne"
    behaviorConfiguration="txServiceBehavior">
    <endpoint
     contractType="ServiceOne.ITxServiceOne, ServiceOne"
     address="http://localhost:35000/TxServiceOne.svc"
     bindingConfiguration="txBinding"
     bindingSectionName="wsProfileBinding" />
   </service>
  </services>
  <bindings>
   <wsProfileBinding>
    <binding configurationName="txBinding" flowTransactions="Required" />
   </wsProfileBinding>
  </bindings>
  <behaviors>
   <behavior
    configurationName="txServiceBehavior"
    returnUnknownExceptionsAsFaults="true" >
   </behavior>
  </behaviors>
</system.serviceModel>
</configuration>

Pay attention to the behaviors section, where I declare to manage any exception as a Fault.
Take a look also at the custom binding configuration, defined in order to require transactions.
The other service is very similar to the first one.

Lastly here is the main part of client code:

schemas.devleap.com.EntitiesOrder.Order order = new schemas.devleap.com.EntitiesOrder.Order();
order.id = 10;
order.description = "Order 10";

TransactionOptions options = new TransactionOptions();
options.IsolationLevel = IsolationLevel.ReadCommitted;
options.Timeout = TimeSpan.FromSeconds(30);

using(TransactionScope scope = new TransactionScope(TransactionScopeOption.Required, options))
{
TxServiceOneProxy svcOne = null;
TxServiceTwoProxy svcTwo = null;

try
{
  // External transactional activity
  svcOne = new TxServiceOneProxy();
  Console.WriteLine("Service One: {0}", svcOne.SaveOrder(order));

  try
  {
   // Internal transactional activity
   svcTwo = new TxServiceTwoProxy();
   Console.WriteLine("Service Two: {0}", svcTwo.SaveOrder(order));

   // Transaction commit, in case of success
   scope.Complete();

  }
  finally
  {
   // Internal channel closing
   svcTwo.Close();
  }
}
finally
{
  // External channel closing
  svcOne.Close();
}
}

Here you can find all the code of the demo solution I developed to test WS-AT support in Indigo.

In order to make it work, don't forget to download this fix (published on 21/06/2005):

http://www.microsoft.com/downloads/details.aspx?familyid=32187993-4736-4a06-97c7-1282b67e3137&displaylang=en

I hope you'll enjoy your Indigo transactional experience :-) !

One day conference about SOA and Smart Clients development

paolopia — Sat, 27 Nov 2004 14:30:00 GMT

I'm working on a Conference Day about SOA and Smart Clients development with Microsoft .NET Framework. It will be on Friday 14 of January 2005, here in Italy, in my town (Brescia). If you're Italian and you like to come .... catch the date and stay tuned on my blog.

FABRIQ: Architecture for High Performance, Decentralized, Agent-Oriented, Connected Applications (ARC405)

paolopia — Wed, 30 Jun 2004 13:34:00 GMT

Good session about FABRIQ, a new framework defined as an "Agent Oriented Architectural Pattern".
The idea is to provide a framework to architect and develop applications that need:

Scalability
Processing of incomplete informations
Latency of messages
Long running operations and/or transactions

Some requirements for architectures that can be handled by FABRIQ are:

Elastic processing
Quick scalability
Break complex tasks into smaller one
Maximize throughput

The solution is based on

Primitive handlers (routing, mapping, transform, log, encrypt, etc.)
Processing units: composition of primitive handlers in a pipeline
Networks: composition of processing units, based on routing rules, that move messages through pipelines of processing units (something like and EndpointReference linked list)

Key point: all messages are delivered with a one-way messaging paradigm. Messages move through agents.

Caveat: "An agent is a self-contained, problem-solving system capable of autonomous, reactive, pro-active, internally motivated, social behaviour". Those agents don't relate to Business Agents mentioned by Don Box yesterday.

From an implementation point of view we have:

Message: the class representing a message. Can handle messages of any size, also very big one (like stream of hundreds of MB). Handles the body as an XmlReader. Provides access to Headers as a MessageHeaderCollection of MessageHeader.
IMessageHandler: base interface for message handlers. Provides a method: bool Process(Message);
We can build chains of Handlers using IChainableMessageHandler implementations.
IFabriqMessageHandler is the base interface for transaction message handling. Transaction are based on two phase commit paradigm with Prepare() method and the consequent Commit() or Abort() one based on vote of the handlers.

Key point: FABRIQ is hosted in Enterprise Services, not in IIS/ASP.NET. We can receive messages through ASP.NET using a IHttpHandler implementation (FabriqHttpHandler) that simply enqueues the messages into a MSMQ queue for standard processing by the FABRIQ engine.

A great feature of FABRIQ is the configuration management in case of many nodes in load balancing. In fact Clemens showed us that FABRIQ uses itself to dispatch configuration files and also .NET assemblies, eventually required, to all FABRIQ nodes automatically. Great idea guys!

Key point: from a security point of view FABRIQ is based on WSE2 engine, using OASIS WS-Security and WS-Policy. Internally messages are converted from SoapEnvelopes to FABRIQ messages and back.

Questions for Clemens:

What about asynchronous message handlers? I can't find them. Probably because from a pipeline point of view we can not parallelize the jobs, should we use parallel nodes with routing rules?
Can we cover different nodes under the same two-phase commit transaction?
What about request/response paradigm? What should I do in order to be able to provide answers to clients? Should I use a request/response Web Service as a front-end and a FABRIQ back-end? Should I use a MSMQ to inform my clients of the outcomes? What else?
In case of failure we have the capability to handle transactions. How should we inform our clients of the problem?
Why did you re-defined ThreadPool? In order to have many thread pool in the same AppDomain and with customizable size? Or am I missing the point?

BizTalk 2004 for the Visual Basic and C# Developer (EBZ214)

paolopia — Wed, 30 Jun 2004 09:28:00 GMT

Great session! Scott Woodgate is a guarantee! It was a 200 level session, so not so deep in BizTalk architecture and programmability, but really a good session!
Aside from the "standard" contents of a session like this, Scott showed us a wizard, fully integrated with VS.NET, to create BizTalk Adapters that he's working on. He told us that it will be available in a few days, probably next week, on his blog. Good job Scott! Thanks!

Service-Orientation and the Windows/.NET Developer (CTS200)

paolopia — Tue, 29 Jun 2004 17:30:00 GMT

A non-standard :-) session, based on Q&A instead of slides ... It was a good idea Don, expecially in a session late in a long day.

The key concepts of this session, as I understood since my bad English understanding :-), were:

SOA: Set of ideas for structuring software
Protocols: not just ideas but concrete to move the bits on the wire
Web Services: a set of protocols
Protocols natively supported by Indigo (out of the box ... in the future...)

SOAP over HTTP (one-way and request/response)
SOAP over TCP

Not faster than HTTP
Duplex messaging

SOAP over IPC (locally for security reasons)

Faster than HTTP and TCP
Duplex messaging

SMTP: there's no time... if we won't Indigo before 2009 :-)
MSMQ: why not ... may be...

A kind of TCPChannel + BinaryFormatter will not be supported because in .NET Remoting, using tcp+binary, there're some issues:

Version brittleness: you pay the pains of versioning
Performance issues: it's good but not great, because of lack of testing and evolution during the time
Security-ness: there's no security built-in

In order to work with a "contract-first" approach in .NET 2.0 we can:

Use WSDL.EXE /SERVER as before
WhiteHorse designer
WSDL (XML) editor provided by VS2005 with intellisense (great!)
Third party tools :-)

OO is like microelettronics. Every microchip needs its socket, with the right number of pins. When we use Objects we're using something with which we're always 100% comfortable and build to do exactly what we're asking it to do. Object are difficult to version. There's no way to have real transparent versioning.
SO is for agile development and deployment, for field replacement and great versioning. Share schemas and contracts in order to achieve these goals. SO doesn't require to share DLLs on both the sides. So deployment and versioning are easier than with OO.
SO in Longhorn:

for instance WMI will be redone in SO

Business Agents: the next buzword (in TechEd 2006... stay tuned :-) !)

Many other questions will be answered on Don's blog.

soap.msmq Transport for WSE2

paolopia — Fri, 25 Jun 2004 15:35:00 GMT

Thanks to Roman Kiss we are able to move SOAP messages over MSMQ with WSE2 !!!

http://www.codeproject.com/useritems/SoapMSMQ.asp

Offline Application Block: persistent MSMQQueueStorageProvider

paolopia — Sat, 19 Jun 2004 22:47:00 GMT

Microsoft Smart Client Offline Application Block makes possible to build applications that are network aware and that are able to work online or offline. When offline you can enqueue messages for central services using many different kind of QueueStorageProvider. One of the pre-built QueueStorageProvider is MSMQQueueStorageProvider that, as you can argue from its name, is a queue provider based on MSMQ. It works with a private queue not transactional by default. Sometimes it happens that you would like to make your messages persistent in order to keep trace of them in case of your Smart Client host shutdown, reboot, crash, etc.

In order to have a MSMQ Queue that keeps track of messages even if you switch off your client you need to mark your messages as Recoverable. To do that you can do either of:

Set to true the property Recoverable of a System.Messaging.Message instance before enqueueing it
Mark the queue as transactional

By default MSMQQueueStorageProvider, doesn't use a transactional queue and doesn't mark a message as Recoverable.
Here is a code snippet to replace in MSMQQueueStorageProvider in order to have Recoverable messages:


/// 
/// Responsible for storing array of bytes into MSMQ
/// 
/// Object as a byte array to store into MSMQ
override protected void DoEnqueue(byte[] objectToStream)
{
 Message msg = new Message(objectToStream);   
 msg.Formatter = queue.Formatter;
 msg.Recoverable = true;
 queue.Send(msg);
}