WCF

Intra-Process Communication Transport

Rick G. Garibay - The more I learn, the less I kno — Tue, 15 Apr 2008 00:56:55 GMT

I met Roman Kiss in person at the MVP Summit today, and had a great conversation about how to provide an intra-process solution when performance is critical and you don't want to pay for the creation of transport channels unless you absolutely have to.

Roman has done a fantastic job documenting this on CodeProject: http://www.codeproject.com/KB/WCF/NullTransportForWCF.aspx

The idea is that even IPC requires necessary transport channel creation to marshall between processes. The Null Transport, as Roman calls it, provides communication within the same Application Domain. So, it isn't as close to the metal as you can get, it *is* bare metal.

This is a brilliant approach to providing intra-process communication within SOA while providing the same level of flexibility that any WCF client/service gets via binding/transport choices that are, for the most part, post-depoloyment decisions.

Silverlight 2.0 Service Integration: Three Steps Forward, Two Steps Back

Rick G. Garibay - The more I learn, the less I kno — Fri, 07 Mar 2008 16:30:19 GMT

Every time a brand new technology comes out, the focus is always on the problems that it is specifically designed to solve. Beneath the patina of a sexy new technology are the result of compromises that had to be made for which very mature, sophisticated stories already exist.

Such is the case, in my opinion with Silverlight 2.0. While the new version boasts some significant improvements with new controls, improved designer tool support and richer FCL support, the integration story is still a bit weak. Although there are some very important key improvements since 1.1, including WCF support (which is limited as we'll see later), there are some aspects of integration that are confusing, if not downright frustrating.

WCF SOAP Support

Silverlight 2.0 now supports Windows Communication Foundation, and allows you to add a reference to a service endpoint using the same convention for any client. Unfortunately, the only binding currently supported for working with SOAP services is BasicHttpBinding. While embracing WS-I Basic Profile 1.0 is great from a standardization perspective, it is unfortunate that some of the WS-* features that I have come to take for granted including WS-AtomicTransactions and WS-Reliable Messaging are neither supported, nor officially planned for support. I am confident that this is coming; it is just not high enough on the team's product backlog.

What did very much interest me is that only asynchronous invocation of WCF proxies is supported. This is interesting to me on two levels. First, because Silverlight CLR runs on the browser thread, the team was rightfully concerned with long running synchronous calls that would essentially block the UI thread. However, when I asked the Product Manager leading the talk if the threads for doing background work come from the thread pool or are marshaled back and forth from the browser to native threads, he wasn't sure. This leads me to the second interesting point which is this. If Microsoft is prescribing an asynchronous programming model for WCF because it simply has an opportunity to do so, then I half-heartedly applaud them for doing so if it due to architectural limitation of Silverlight. What I mean is that I think it is time for all architects and developers to think more about pub-sub, and if this is Microsoft putting a stake in the ground, then that is fine, but you should still give developers the option to go synchronous. I'd be interested in anyone's thoughts on this because it is a bit irksome:

var proxy = new ShoppingServiceClient();
proxy.GetProductsCompleted += new EventHandler<GetProductsCompletedEventArgs>(proxy_GetProductsCompleted);

proxy.GetProductsAsync(“book”);

void proxy_GetProductsCompleted(object sender, GetProductsCompletedEventArgs e)
{
// Process response…
}

From an encoding perspective, WCF support is strictly SOAP based which makes sense. However, keep in mind that in Silverlight 1.1, JSON was the first-class seralization format and this is a clear departure from that. Again, this begs the question as to whether the choice to support SOAP natively was intentional, or a direct result of providing a WCF integration story. To be honest, JSON doens't make sense in pure Silverlight scenarios because there is no JavaScript interop happening. It’s all Silverlight CLR. That said, there are some significant performance benefits to JSON which leaves me guessing as to whether it will be supported as an alternative WCF encoding in the future.

Unfortunately, Faults are not supported, and I don't really understand why.

HTTP & REST Support

I have some opinions on REST that are probably quite bellicose, so I will save them for another post. That said, Silverlight 2.0 does support basic HTTP invocation via GET and POST for low-REST scenarios. The weapon of choice for "Human Readable Documentation" services is a class called WebClient in the System.Net namespace which basically takes a URL and returns a response. While there is no hard and fast rule about what a REST service provides, assuming that it is XML you can use XMLReader and XMLWriter along with Linq to XML to work with XML results. Now, if you are really a contortionist, are using REST and want serialization support, you can of course build out your entities to map to the XML coming back and deserialize the response stream using XmlSerializer, but I just don't understand why you would go through all this trouble when SOAP tooling does it all for you. OK, I slipped. I couldn't help myself, sorry.

Sockets/TCP Support

Scott Guthrie makes mention of support for sockets on his blog (http://weblogs.asp.net/scottgu/archive/2008/02/22/first-look-at-silverlight-2.aspx ), but this wasn't covered at any of the sessions I attended.

Security

This was the most vague aspect of the sessions I attended because the focus was not on authentication or authorization, but rather on a flavor of code access security that determines whether a service can be called from a client from another domain and vice-a-versa.

There was mention that if you enable ASP.NET Compatibility in your WCF service, you can glean the identity of the user running the browser via the canonical HttpContext.CurrentUser property, but it was unclear to me if the browser identity is that of the user logged in to the machine, what the implications of enabling/disabling Integrated Windows Authentication on IE browsers, and how this would work with non-IE browsers.

This is important to me from a resource access perspective. If I am using Silverlight to communicate with a service that isn't just wide open, I am going to want to perform some authorization to ensure that at the very least, I can support a trusted subsystem model, because I don't want to deal with n potential users.

Summary

To wrap up, I think there are exciting things to come with Silverlight 2.0, and I think it is going to challenge many of us to think about how we integrate with the cloud. I see a trade-off, if not a gamble happening between SOAP and REST within the Silverlight team, and the winner may depend on which standard is considered the most "weby". This concerns me because of how fickle the web can be, and I'd hate to see the tremendous gains made around integration and SOA, particularly with WCF, get lost in the hype. In the end, I think that this one will be ultimately decided by the constituents that make up this new landscape of information democratization known as Web 2.x.

Creating a Hybrid Binding

Rick G. Garibay - The more I learn, the less I kno — Fri, 09 Nov 2007 05:49:04 GMT

I am currently working on building a hybrid WCF binding. I want to build a custom binding to address a common problem domain that no existing bindings out-of-the-box address directly. As you will see, this is by no means a limitation of WCF, in fact, it is with WCF that I am actually creating the custom binding.

Specifically, I want a binding that will allow me to host a service in IIS so that I can take advantage of the IIS hosting model which will immediately provide message activation and a robust transport security platform essentially for free. In addition, I might have a network topology between endpoints such that firewalls will be involved so I might want to use port 80 to allay any concerns by the router cops. I also want to take advantage of reliable messaging using the WS-Reliable Messaging specification so that I can get delivery assurance between endpoints as well as the ability to flow transactions from endpoint to endpoint using WS-Atomic Transactions.

Last but not least, I want to take advantage of the binary encoder that is used by default in the NetTCPBinding so that message payloads are compact and optimized.

I am calling this binding NeuNetHttpBinding because I want to combine the best of both worlds that the NetTcpBinding and WSHttpBinding provide.

So what's the "Neu" for? Well, the good guys at Neudesic sign my paycheck so it is only natural to give them props for letting me have so much fun and still get paid for it!

Now that you understand the heritage of the binnding, let's talk about how I might accomplish this.

Creating a custom binding can be done in one of two ways. The first is using straight configuration, and the second requires working for a living and writing some code!

I am a big fan of the fantastic way in which WCF seperates the service implementation from hosting details and this approach definetely has its place in most scenarios. In this scenario, however, I don't want to give an adminstrator this ginormous configuration file that needs to be duplicated across several services. I also don't want them to have to worry about all the configuration switches to get things just right, and I especially don't want them twiddling knobs that will only break the service model.

Regardless of the approach taken, there are some canonical rules that must be followed in building a custom binding in accordance to the layers that make up each and every binding.

Below is a table that summarizes each layer, the binding element or property that represents each layer and whether each layer is required:

Layer	Options	Required
Transaction Flow	TransactionFlowBindingElement	No
Reliability	ReliableSessionBindingElement	No
Security	Symmetric, Asymmetric, Transport-Level	No
Shape Change	CompositeDuplexBindingElement	No
Transport Upgrades	SSL stream, Windows stream, Peer Resolver	No
Encoding	Text, Binary, MTOM, Custom	Yes
Transport	TCP, Named Pipes, HTTP, HTTPS, MSMQ, Custom	Yes

As you can see, the only two layers that are required for a binding are transport and encoding. You will also notice that there is a layer dedicated to Security, Reliability and Transactions.

You can really think of bindings as nothing more than a configuration store that is read by the service model at runtime. The binding is actually interpreted at runtime and the appropriate channel factory and channel listeners are created on the client and service respectively and these channels are what make the magic between the endpoints happen.

More to come...

Image Uploads with WCF

Rick G. Garibay - The more I learn, the less I kno — Tue, 16 Oct 2007 02:42:01 GMT

I am building a service that uploads images from a client to a UNC share. The service is built with WCF (what else) and I must say it is pretty slick.

To serialize images, you basically convert the bits into a byte array, serialize the array and away you go.The service I am working on takes advantage of the MTOM (Message Transmission Optimization Mechanism) encoding, which significantly improves the perfornance of larger payloads, which are usually common when dealing with images.

MTOM is a good choice when you are working with large binary attachments, regardless of transport protocol. For example, if you are using HTTP, MTOM is an excellent choice for optimizing the handling of binary data. In addition, TCP will also gain substantial improvements from using MTOM for large binary attachments.

One of the things you should know when dealing with larger message sizes, specifically, those that exceed 65K. Attempting to submit an image (message) larger than 65K will result in a 400 Bad Request error at the server.

Once you have a good idea of how large the images are going to be, you will want to adjust the maxReceivedMessageSize property on the binding of choice. The default is 65K which may be too small for most scenarios, even with low res images. Below is an example of a custom binding configuration you can use when using large message uploads:

Notice the messageEncoding is set to "Mtom", and I've set the maxReceivedMessageSize to 2MB, matching it with the readerQuota. Both are just many of the switches and knobs at your disposal in WCF configuration and is another great example of how WCF is secure by default.

While MTOM does optimize large binary transfers, there is a point of diminishing returns if the binary data is not big enough to really get a boost from MTOM. For example, the payload of a moderate binary upload may be smaller than that of which is MTOM encoded because the MIME notation itself does introduce a swell in message size.

As a rule of thumb, always do some performance testing to ensure that you aren't hititng the head of a pin with a sledgehammer.

System.Diagnostics.DebuggerStepThroughAttribute()

Rick G. Garibay - The more I learn, the less I kno — Tue, 25 Sep 2007 16:55:41 GMT

It was at the eleventh hour and I am trying to debug a WCF proxy with no luck. I knew that the call was crossing the process boundary because I was catching a Fault Exception, but when its late and things get hinky, I wanted to ensure that I was calling the right method on the channel.

My friend and collegue David Barrett pointed me to the fact that the proxy class is decorated with the following attribute:[System.Diagnostics.DebuggerStepThroughAttribute()]

I am not sure what value this provides, unless you want to hide the details of the proxy from developers when stuck in the muck, but removing the attribute seems to work!

MSDN Events: Building an Effective Messaging Infrastructure with WCF

Rick G. Garibay - The more I learn, the less I kno — Tue, 18 Sep 2007 04:21:12 GMT

I will be doing a talk for MSDN events on Windows Communication Foundation. This is a level 200 talk that includes a combination of content from the MSDN team and my own. Even if you have seen my fundamentals talk on WCF, this session is guaranteed to include new content and code samples.


	Topic: Building an Effective Messaging Infrastructure with WCF Date: Wed., Sept. 26, 2007 - 1:00-5:00 PM Pacific Time Location: Microsoft Southwest Office - Phoenix, AZ

	Abstract: Windows Communication Foundation (WCF) brings tremendous power to developers and architects who are charged with creating distributed systems, but the many coding and configuration choices within WCF can be daunting. When faced with an almost infinitely configurable system, how can you be sure you’re utilizing WCF effectively? Learn how to solve the real-world technical problems that led you to WCF in the first place. This session will educate and inform both developers and architects about how to build and configure services in WCF using a variety of real-world scenarios as examples. After a brief review of WCF’s code concepts, we’ll explore techniques for building an effective messaging infrastructure, taking advantage of WCF’s many built-in services, including security, transactions, reliability and durability. You’ll learn: • How to build and configure services in WCF • WCF core code concepts • Techniques for building a rock-solid messaging infrastructure • How to maximize WCF services, including security, transactions and durability
	Registration: Please register by clicking the event link below, or by calling (877) 673-8368 (877-MSEVENT) and referencing Event Code # 1032351524.
	Read More & Register for Event (Microsoft.com Events Site - Event Code # 1032351524)

Desert Code Camp III: Building WCF Services for Deployment in Transiently Connected Networks

Rick G. Garibay - The more I learn, the less I kno — Sun, 26 Aug 2007 19:20:19 GMT

This is the second talk I will be doing at DCC III. It ties in nicely with the first article in a WCF article series I am doing for CoDe Magazine due out in the November/December issue, so if you are interested in a sneak peak, I hope to see you there.

Topic: Building WCF Services for Deployment in Transiently Connected Networks

Date: Saturday, September 15th, 8:00 am to 5:00 pm.

Location: University of Advancing Technology

Abstract:

Mobile devices (be it handhelds or laptops) are now prolific in the enterprise, and more and more users are relying on mobile connectivity so that they can remain productive anywhere and at anytime. So what happens when the network goes down, or a WiFi dead spot is encountered? Or asked a different way, how can you provide the user with the best connected experience based on the state of the network?

In this code-focused discussion, we’ll look at a line of business application built using WCF and Visual Studio 2005 that exposes HTTP, TCP and MSMQ endpoints so that that the client can use the most suitable connection based on the state of their network connection without compromising reliability.

Deck: rickgaribay.net/Resources/PublishedContent/DCC3/Microsoft PowerPoint - Neudesic WCF Reliability - DCC.pdf

Code: **

** As this code will be part of the my fortcoming article "Building WCF Services for Deployment in Transiently Connected Networks, A Reliability Trifecta" for CoDe Magazine, I am unable to make this code available until the article is published. Please stay tuned...

WCF IIS Hosting Gotcha

Rick G. Garibay - The more I learn, the less I kno — Tue, 10 Jul 2007 13:30:00 GMT

I have been a strong proponent of taking the seperation of interface and implementation all the way down to the IDE. For example, a WCF service just might happen to be hosted in IIS 5/6 today using HTTP, but tomorrow, that service should be able to move, transparently to IIS 7 WAS and be bound to TCP, IPC, MSMQ or any other supported transport protocol.

For this reason, I advocate using class library project templates so that the service can be self-hosted using Windows Services or any other host process and not be intrinsically tied to IIS.

There is one gotcha, however.

When Visual Studio builds a class library project, it uses the default configuration that places the assemblies in the bin/debug folder. IIS doesn't probe the /Debug folder, so you will get the following exception:

The type 'Services.MyService', provided as the Service attribute value in the ServiceHost directive could not be found.

The solution is to either copy the assemblies from the bin/debug folder to the root of the bin folder, or change your debug settings in Visual Studio to do the same. To do so, go to Properties (right click the project), select the Build tab and change the Output Path from "bin\Debug\" to "bin\".

Note that using the Web Application Project template (available for Visual Studio 2005 with SP1) adheres to this behavior by default, but again, in keeping your services transport/binding agnostic, I recommend using a class library template or better yet, create your own template!

Managed Windows NT Services, Application Domains & Principal Policy

Rick G. Garibay - The more I learn, the less I kno — Thu, 10 May 2007 17:34:58 GMT

Update to orginal post: After doing some more research, the actual problem turned out to be that the legacy Windows NT service never specified the WindowsPrincipal and had nothing to do with the Gateway assembly. In fact, it turns out that when you load a class using Activator.CreateInstanceFrom(), the class loads into the same parent application domain. I've updated the solution below appropriately.

Thanks to Rick Strahl for clarifying the Activator.CreateInstanceFrom(), app domain behavior. You can also find an excellent article by Rick in CoDe magazine that covers this extensively: http://www.code-magazine.com/article.aspx?quickid=0211081&page=1

- - -

I recently ran into a security problem in a somewhat typical scenario for which the specific details I imagine are fairly esoteric because I was unable to find anything relevant on the web or on MSDN forums. It is amazing how easy it is to forget (or at least suffer from delayed recall) fundamental aspects of the framework when you are in the thick of it and trying to ship a product!

So, I figured I’d post an overview of the scenario and the solution to the problem in hopes of helping anyone else who runs into this.

Scenario

A common approach for setting up any kind of automated process is to use a Windows NT service which is continually running, monitoring a queue or database for records/messages that represent events for wich some work should be performed. For example, I can have a Windows NT Service monitor a private queue every 5 seconds, and when a message is available, process it (whatever process means for the given service).

One option for the processing bit would be to raise and event and delegate the work out to a method that would maintain all of the event handling logic. This handler could reside in a single class within the same assembly as the service, but for obvious reasons this could quickly get unruly and introduce a maintanance nightmare. If every time you need to change the event handling business logic you had to recompile and redeploy the service executable, although you might be building job security, you'd find yourself getting frustrated at best and at worst, you would be tightly coupled to a single assembly making it difficult to leverage this pattern in a more abstract, loosely coupled manner.

One possible solution might be to apply a typical publish and subscribe pattern where the Windows NT service polls a backing store (or ideally was notified automagically) and when a record (or message) meets a specific criteria fire an event. The event would then be mapped to a delegate which implements the handling of the event. However, to keep the implementation of the handler from being static and hard coded, we could further delegate the implementation of the work to an external component, making the original event handling delegate only worry about the plumbing for dispatching the work to another component. Ideally, this would allow a plug and play approach where assemblies could be "dropped" in and just work. Of course, this would require that the message in a queue has some kind of metadata about the component to execute (such as assembly name, type and URI) and when the event is fired, the handler gets access to this URI and dispatches the call to it.

This is precisely what the System.Activator class allow you to. If you know the name of the assembly that contains the component you want to call, simply call the CreateInstanceFrom method on the Activator class. The CLR will then probe the local private directory for the assembly name, load it and instantiate an instance of the type. Figure 1 below summarizes what this might look like.

Figure 1: Mock Sequence Diagram

When the IGateway object is “unwrapped” and made available to the MyNTService Windows NT Service, the service can call a method (or methods) on the instance to do some work. To achieve polymorphism, since the Gateway component that is unwrapped implements the IGateway interface, the service is guaranteed to be able to call a particular method (Execute, in this case).

Figure 2 (below, right) provides a possible object model that supports this design.

The purpose of the Gateway class is to serve as wrapper around a component/service call while maintaining location transparency. This can thought of as a "super proxy" and is really just the classic Service Gateway/Service Agent pattern. The MyNTService Windows NT Service has no idea if the component is local to the machine or process or somewhere out in the cloud. With this flexibility comes significant power in being able to make decisions on distribution in a post-deployment manner.

As the saying goes “with great power comes great responsibility”. Looking again at the sequence diagram in Figure 1, two important things need to be considered.

First, this scenario demonstrates WS-I Profle interop between a WCF service and a managed Windows NT Service running on .NET 1.1 CLR (pretty cool huh?).

Second, between every call in the sequence is an authentication and authorization boundary. Though impractical, the Gateway component could ensure that only the identity of the Windows account running the MyNTService Windows NT Service can call it’s Execute method. More importantly, however, the Gateway should flow the identity of the Windows account running the MyNTService Windows NT Service process to the WCF service that is out in the cloud so that the WCF service can authenticate and authorize the call. Pretty simple,right?

Problem

Well, one of the things that may not be overly apparent is that the assembly in which the Gateway type that implements the IGateway interface resides will actually load in the same application domain that exists within the host NT service process. The MyNTService Windows NT Service knows NOTHING about the Gateway component (other than that it implements a standard interface). When an instance of the Gateway component is activated, we want to run in the security context of the parent process (of the MyNTService Windows NT Service ), however if the host application domain has not specifically set the the Principal Policy, the component will execute with no security context, or to be a bit more technical, will load using the default UnauthenticatedPrincipal enumeration flag. This basically means that the principal under which the MyNTService Windows NT Service is running will not be attached to the thread on which the Gateway component runs. In fact, as the MSDN documentation for the System.Security.Principal.PrincipalPolicy enumeration states “Specifies how principal and identity objects should be created for an application domain. The default is UnauthenticatedPrincipal.”.

Solution

Those keen to the default behavior regarding application domains and Windows Principals already know where this is going, but for those who aren’t sure, stay with me.

Although the MyNTService Windows NT Service was running as a fixed domain account, the WCF service requires transport level authentication and uses role-based authorization to ensure the caller (MyNTService) is authorized. However, calls from the MyNTService Windows NT Service via the Gateway were failing with "The request failed with HTTP status 401: Authorization Required."

I triple checked IIS security settings. My unit tests worked just fine. My test harness also worked and even browsing to the service’s metadata page was working. For some reason, the Gateway was calling the WCF service in a seamingly anonymous manner. This threw me for a loop for a couple of days.

Then, a few days ago, while in the shower (I get many of my “light-bulb on” moments in the shower or in my dreams for some odd reason) the solution hit me like a thunderbolt! The Gateway assembly was being loaded without an authenticated principal, and hence the solution was simple, sweet and elegant:

AppDomain.CurrentDomain.SetPrincipalPolicy(System.Security.Principal.PrincipalPolicy.WindowsPrincipal);

Now the Gateway took on the identity of the Windows AD account that was running the Windows NT Service process and was able to authenticate to and be authorized by the WCF service.

You can find more info on principal policy and application domain behavior here: http://msdn2.microsoft.com/en-us/library/90395801.aspx

WCF Performance

Rick G. Garibay — Tue, 24 Apr 2007 21:44:53 GMT

Excellent paper comparing WCF performance to some of it's contemporaries such as ASMX and .NET Remoting.

http://msdn2.microsoft.com/en-us/library/bb310550.aspx

To summarize the results, WCF is 25%—50% faster than ASP.NET Web Services, and approximately 25% faster than .NET Remoting.