Lesser coupled WCF Services.
I hear people talk about how WCF or ASMX services are inherently loosely coupled by default out of the box, whether they use HTTP or TCP or any old transport available for that matter. “Just use Web Services or WCF and you get loose coupling for free” they say. So the story of temporal coupling using Web Services is well known now as are the many issues with platform coupling and indeed the solution below does not address platform coupling directly as it leans on XML to manage serialization. The coupling that I am interested in addressing here is that created by dependency to the ubiquitous proxy or WSDL contract. Lets examine this a little more closely.
The Reason:
The most common method for a consumer of a service (WCF / ASMX) to maintain and manage the resolution to it’s interface is WSDL. This requires each consumer having to carry around the contract with it, forever in it’s servitude to understand the mysteries that lie at the boundary of it’s faithful service. So without this proxy I don’t know what message to send and where to send it (and yes I know you don’t have to use WSDL and you can proxy off the interface - but that leaves us still coupled to the service interface). Coupling is a measure of dependency and because our consumer depends rather heavily on the service interface or WSDL it is quite squarely coupled to it. Version control with WSDL isn’t trivial to manage and so the coupling story gets worse when we want to change the interface. WCF does provide some methods to relax this versioning problem by ignoring parts of messages from old contract consumers however this is still not adequate. We also hit the coupling ceiling when you consider that all my endpoints are bound to particular message types with respect to the message sent and returned. More recently prescribed guidance has suggested a pattern in sending more coarsely grained messages that are less chatty by utilising complex types or [DataContract] in the world of WCF, but unfortunately I’m still coupled to the schema of these big messages.
How to address this?
One way of addressing this would be to provide blandly consistent service interfaces that never change and utilise the most generic of all messages - System.ServiceModel.Channels.Message, otherwise known as an untyped message in WCF. We can bundle up our rich business messages (as serialized POCO’s) and send them in the body of the untyped message. Once having arrived at our bland endpoint, we could check for an appropriate handler of this message (POCO). What’s required is to de-serialize XML out of the body of our untyped message and back into a POCO and then have the handler manage the message for which it was built to handle. Below is a really rudimentary way of thinking about this interaction.
The Code for sending the message could look something like this:
public void ExampleSend() { //create a channel to the BUS EndpointAddress address = new EndpointAddress (“net.tcp://localhost:9002/Org.ItResults.” + “Soa.Hosts.HumanResourceServiceSvc”); NetTcpBinding binding = new NetTcpBinding { SendTimeout = new TimeSpan(0, 10, 0) }; ChannelFactory<IEndpoint> factory = new ChannelFactory<IEndpoint>(binding, address); IEndpoint channel = factory.CreateChannel(); TestMessage tm = new TestMessage(Guid.NewGuid()); XmlReader reader = Serializator.SerializeMessage(tm); //Create the Message to put on the BUS //with the serialized data contract embedded //into its body and the target method //at the endpoint for the BUS channel Message msg = Message.CreateMessage( binding.MessageVersion, “urn:BaseEndpoint-Recieve”, reader); //send the message onto the BUS channel.Recieve(msg); //Close the comms factory.Close(); }
On the receiving side the code might look like the following:
public void TestReceive(Message msg) { //NOTE: the types of T handlers could be //loaded into the host process //a library where an appropriate //set of handler might be located const string path = @”D:\LocalWorking\ITResults\” + “Org.ItResults.ServiceOriented.System” + @”\Org.ItResults.Soa.Poc.Messages\bin\debug“; //get all the types in the path that have //generic args. They may be Message Handlers //for messages (the generic args) List<Type> generics = GenericTypeReader .InterfaceTypesInPathWithGenericArgs(path); List<object> unravelled = new List<object>(); //for each type found with a generic arg //try to deserialize the body of the message //in the endpoints method arg into each //generic type found generics.ForEach(t => unravelled.Add (Serializator.DeserializeMessage(msg, t))); unravelled.ForEach(delegate(object o) { //find a handler for the deserialized object IMessageHandler handler; handler = GenericTypeReader. FindHandlerForMessageTypeInPath<IMessageHandler> (path, o.GetType()); handler.GetType(). GetMethod(”HandleMessage”) .Invoke(handler, new[] { o }); }); }
Where a message handler looks something like:
public interface IMessageHandler { } public interface IResponseMessageHandler<T> : IMessageHandler where T : IMessage { /// <summary> /// Handles messages that are not required /// to return a response. /// </summary> /// <param name=”message”> /// The type of message to handle. /// </param> Message HandleMessage(T message); } public interface IOneWayMessageHandler<T> : IMessageHandler where T : IMessage { /// <summary> /// Handles messages that are not required /// to return a response. /// </summary> /// <param name=”message”> /// The type of message to handle. /// </param> void HandleMessage(T message); }
And finally the message and it’s concrete handler might look like this:
public interface IMessage { Guid ID { get; } } [XmlRoot(Namespace = "Org.ItResults.com.au")] public class TestMessage : IMessage { private Guid _id; private string _nameofMEssage; #region IMessage Members [XmlElement(Order = 1)] public Guid ID { get { return _id; } set { _id = value; } } #endregion public TestMessage() { } public TestMessage(Guid id) { _id = id; } [XmlElement(Order = 2)] public string NameOfMessage { get { return “Test Message”; } set { _nameofMEssage = value; } } } public class TestHandler : IOneWayMessageHandler<TestMessage> { #region IMessageHandler Members public void HandleMessage(TestMessage message) { Console.WriteLine(“The Test Message name was “ + “{0} and it’s ID is {1}”, message.NameOfMessage, message.ID); } #endregion }
It’s evident from the code that I should be able to drop message handlers (contained in libraries) in a library folder close to my service and give that service the ability to handle messages defined by handlers in those libraries. This is very similar to how nServiceBus deals with declaring how a service defines what messages it handles and I have adapted the idea to fit with WCF, which affords us the following:
- Decouple from any WSDL proxy and it’s associated versioning issues.
- Proxies are now managed via a consistent interface less likely to ever require change, as messages pass in the body of an untyped message.
- Release newer versions of message handlers to services without rebuilding against them or any newly refreshed proxy definition.
- Freedom from carrying around WSDL.
- No coupling to API CRUD styled service endpoints.
- This is where the style of using Handlers becomes important. Developers are not required to understand an RPC styled API that describes how to affect the state of underlying data, which more often than not is the legacy found in default Web Service Architecture.
It’s also worth noting that the code above does not list how to deal with return messages contained in the untyped message body of an IResponseMessageHandler<T>. This would be managed in a similar fashion to discovering the correct handlers at the service endpoint, by attempting to deserialize messages into available handlers.
Something that is missing in this example is the ability to do publish and subscribe. Some of my colleagues and I are working on a proof of concept framework that extends the concept demonstrated in this post and will include how to handle Pub / Sub (no duplex channels), endpoint discovery via PNRP and durable messaging using queues (Service Broker Queues).
