thinking-out-loud

Advanced WCF Development

I've recently had the opportunity to join a client's team building an ESB solution using the Windows Communication Foundation (WCF) with requirements for security, logging, load distribution across a managed group of hosts, and more.  As you can see from my list of books here on my site, I spent some free time over the holidays reading up on WCF.  It seems that everything published about WCF so far just covers how to write and host services.

The best organized book I found that presents all the key concepts and somewhat covers extensibility through behaviors is Pro WCF by Chris Peiris and Dennis Mulder.  I've also reviewed Programming WCF Services by Juval Lowy, which has a somewhat shotgun approach development with WCF, great for coding, but doesn't really cover WCF extensibility. 

The best references I've found on extending WCF are Mark Gabarra's blog and this great, detailed MSDN article on WCF extensions by Aaron Skonnard, which gives full examples of extending WCF in a variety of ways, including behaviors.  I'm currently prototyping a WCF service with extensions at a variety of points and will post more as I make progress.

Loosely coupled [my ass]

Ah -- it's good to not feel alone [about this]. Simon fell laments the serialization semantics of WSE's EPR implementation. Via the venerable [his-friends-call-him]  Gudge. Add the versioning problems Clemens talks about, and you start to get a feel for just how great service orientation is. Or maybe how difficult distributed computing is, angle-brackets-be-damned. Moral of the story, kids: Distributed computing is a pain in the ass. Let me extend my guarantee: if you haven't already, you are going to run into these problems. If Simon Fell and Clemens Vasters are having problems with it, you will, too. It's ok. You're not alone.

Hello. My name is Jef, [Hi, Jef] and I have versioning problems.

Grrrr.

WSE Pop Quiz Answers

I have been busy enough to not be motivated to blog lately, but I have a backblog of things that I have been thinking about posting on. Please bear with me if some of these end up sounding like ancient history.

In answer to WSE Pop Quiz 2, the problem, as Joseph alludes in the comments, is that the Microsoft.Web.Services2.Addressing.EndpointReference is not easily serializable because it doesn't have a public default constructor, and so you get "issues" when you try to use it. Some alternatives would be to use a string or uri if you only need the uri bits of the EPR, but if you want things like reference properties, you will have to roll your own class. Disappointing, but in the new era of services, you can easily get the impression that code level reuse is considered evil anyhow :).

If you do roll your own, you can obviously use xsd or wsdl to gen the classes, or you can try Christian Weyer's WSContractFirst. I haven't had much luck with imports use wscf, and I want to be able to generate stubs and skeletons form wsdl porttypes OR bindings OR service elements, and I want to be able to target wse and asmx (and wse'd asmx). I would also like to be able to save config options, so that I don't have to type it all into the dialog each time. The new WseWsdl2 in the WSE 2.0 SP1 does a lot of what I want on the proxy side of things, but no dice on the server side.

Since he hasn't held up to his almost promise to open-source the darn thing :), I am rolling my own, partly because I need it now, partly because it is fun. I will open source it when I get it done (please see busy comment from above). Christian, if you are reading this and you are open sourcing it soon, please let me know, because I would hate to waste the effort if I could contribute to your version.

I am borrowing some ideas from Daniel Cazzu's Custom XSD Code Generation MSDN article. He also blogs about the concept and has a follow-on vs.net tool for custom gen. I am personally not a big fan of the inline annotations, though I suppose you could easily add the annotations to a new schema and then import the target schema -- not a terrible tradeoff, all things considered. I have done work with CodeDom for a (gasp, heresy) "transparent", reflective object relational mapper. I, for one, love object-relational mappers, but I hadn't touched the System.Xml.Schema and Serialization classes too much, so it was a great, fun intro. I especially like the reflective types. Just so that you know which side of the fence I land on. More on that later.

WSE Pop Quiz 2

What happens if you create a vanilla ASMX service that accepts an EndpointReference as an argument? e.g.

// SoapDocument* attrs elided for brevity
// and yes, I started out with wsdl
public class MyWebService : WebService
{
  [WebMethod]  
  public void Accept(EndpointReference e)
  {
    // whatever
  }
}

Try it out. Suggest work arounds in comments if you don't mind. Try them out as well. Let me know how it goes. I came up with a solution, but I wasn't blown away by its beauty or anything. I just thought the reasons for coming up with a work-around were interesting. I'll post it later.

WSE Pop Quiz

Q1: What's the difference between:
http://schemas.xmlsoap.org/soap/envelope/ and http://schemas.xmlsoap.org/soap/envelope ?

A: The former does not yield
"Microsoft.Web.Services2.SoapFormatException : WSE005: The input was not a valid SOAP message because it has either the wrong name or the wrong namespace. The name specified follows: Envelope. The namespace it was defined under follows: http://schemas.xmlsoap.org/soap/envelope" while the latter does.

I don't feel too bad, given that I am not the only one who made the mistake.

Q2: What's the difference between:
http://schemas.xmlsoap.org/ws/2004/03/addressing/ and http://schemas.xmlsoap.org/ws/2004/03/addressing ?

A: The former does not yield any ws-addressing headers while the latter does.

At least soap 1.2
(http://www.w3.org/2001/06/soap-envelope not http://www.w3.org/2001/06/soap-envelope/) is consistent with the ws-stuff.

FYI - in case you are rolling your own soap envelopes for whatever reason (mine was canning some test data).

WSE Wish List

I don't know whether any of you who have sway are listening, but it sure would be nice to be able to disable event logging, or to be able to redirect it to a wse-specific event log. WSE tends to fill up my event log during failure mode testing (sending bad data, unplugging network cables, shutting down services, etc), and that makes it really, really difficult to troubleshoot.

I tried to find a way to disable it in WSE configs somewhere, but had no luck. I am trying to find out if there is a way to disable events by source at the os level, etc, but if there is, I haven't found it. If you know how, I would greatly appreciate your help.

I Service Naked, er, I mean Bare

I followed an interesting, timely thread on using SoapParameterStyle.Bare in your ASP.NET web services. I too am a big fan of the using Bare on the service method.

One additional point of note regarding some comments on compression in HTTP: HTTP compression really only works on responses, and if you move to WS-Security for message-level encryption using, say, WSE, then compression won't buy you much, because the encrypted contents are sufficiently random enough to not compress worth a doody. Reasonably sized, xml data encrypts compresses (thanks for catching the typo, Todd) quite nicely, though. You can try it out for various size files using the following simple method. Go to the web. Download several html pages based on their size. Compress each of them to a zip file using your favorite compression tool. Compare the sizes. You typcially don't want to compress the messages below a certain threshold, but the rest of them, you do.

In general, you would prefer to compress before you encrypt because the encryption cost is usually higher. Morty has an experimental compression filter for WSE, and he discusses the issue further based on his experience implementing it. One problem with compressing ws-security afflicted content is that there is a really good chance that the size of the message due to the security info in the headers, etc is far, far larger than the message you are sending, and you might not be getting much benefit from the compression because your message is sufficiently small. If you are dealing with coarse-grained, document-oriented business services, you might have some meat worth the compression. Of course, there doesn't appear to be anything more than the gleam in a couple of people's eye's at this point regarding compression in WSE.

Via Steve to several posts by Tim leading to some posts and comments by Craig, Richard, and Cleve. No, I am not actually on a first name basis with any of them.

FABRIQ Released

Clemens Vasters announced the release to the wild of the Fabriq sample that newtelligence has been working on with Microsoft EMEA, et al.

I downloaded the bits and have started reading through the code. Clemens explains the architecture and configuration in several recent posts, so you probably want to start there if you didn't get to see this stuff at the various Tech Eds.

One interesting observation is that, though you will find several references to some of the wse namespaces such as Addressing, Security.*, and the base namespace, you will not find references to the WSE messaging layer. Fabriq roles its own transport(s). I have recently come to that decision myself. I have been trying to implement a msmq-based, reliable, transacted transport for wse 2.0. I basically gave up the ghost Friday, after a week of load testing revealed nit after nit that made the code far more complicated than it really needed to be. I basically reimplemented the whole transport in a much more dumbed-down, straight forward fashion, and it took a lot less code. I am going to try to take some time to write up the experience notes, and I will publish them here when I get a chance.

One Nice-to-have would be for the code to be structured so that the architecture was as clear in the projects as it is in the documentation, e.g. adding sub-namespaces to the Core project to package up the concepts, maybe MessageHandler, Pipeline, Node, Action, Router, Transaction, Transport, IO, Utility. It would improve understandability, I think. FWIW -- I tend to use the [most likely fabricated] 7+- 2 rule in packaging things. If a namespace has 10+ classes, I strongly consider reorganizing it. Most of the time, this ends up making the code much better, if only because it is easier to understand. This is what I have always called Extract Package, stealing the pattern naming convention from Martin Fowler. Apparently, I am not the only one. Patterns are like that.

Generic WSE Soap Router Pt. 4

OK -- here is the latest cut. Straight inline. Sorry if the format sucks. Once again, I didn't compile it, but it is a moral equivalent of what I am using successfully in a project, so there ya go. I am still interested in monkeying around with the peer-to-peer, federated referral stuff, so I will keep you posted. I am thinking ip multicast wse transport with really tiny messages.

mmm. multicast.

 
 public class AnyRouter:SoapReceiver
  {
    public AnyRouter()
    {
      Pipeline.IsIntermediary = true;
    }

    protected override void Receive(SoapEnvelope envelope)

    {

      Uri newAddress = ReferralCache.ResolvePath(envelope.Context.Addressing.To.Value);

      if( newAddress == null )

      {

        throw new AddressingFault(

          AddressingFault.EndpointUnavailableMessage, 		

          AddressingFault.EndpointUnavailableCode );

      }

      SoapSender sender = new SoapSender(new EndpointReference(

	envelope.Context.Addressing.To.Value, 

	newAddress));

      sender.Pipeline.IsIntermediary=true;

      sender.Send(envelope);

    }

  }

Generic Soap Router Pt. 3

I fished, Steve bit, and then fought back with a "don't you go using channels directly," um, smack down (sorry for mixing fishing and outdated urban street cred metaphors, but I *am* from Texas). And he is right, excusing the bit about it being a bug. I was using the channel directly because of The Problem. The Problem was that using SoapSender resulted in a seriously bizarre set of soap headers, with problems including duplicate was:Action elements. Now we're talking bug! Of course, the *Real Problem* was that I didn't set IsIntermediary = true on the *Sender's Pipeline*. Silly me. This resulted in a very similar "slap my forehead, I already thought of that, why didn't I do it for both" sort of reaction. Reminds me of the old joke:

patient: "Doctor, doctor, it hurts when I hold my arm behind my back like this..."
patient demonstrates.
doctor: "Well, stop doing that."

I added the IsIntermediary bit to the sender's pipeline, and voila: Success. Consider my version revised. Thanks, Steve.

Now.

He poses a couple of questions that are interesting aspects of intermediary design.

Is trust point-to-point, or end-to-end?

Of course, being a f'in dork and a wanker consultant to boot, I realize that the only appropriate response [that could contribute to additional billable hours] is "It depends." There definitely isn't a one-or-the-other answer to this one. The question depends on the requirements, e.g. how the trust relationship is defined--is it end-to-end or point-to-point? Sorry to answer the question with the same question, but as far as I am concerned, that *is* the answer. I also think it begs additional questions about general intermediary design -- routers that do nothing more than route, in my opinion, should not modify the envelope. As I understand it, that one of the primary motivating factors for moving away from WS-Routing to the next-hop routing and WS-Addressing. Other intermediaries that route as a byproduct rather than as their core competency may or may not need to add their mark to the message, depending on role. I think the answer to the question depends on how far up the stack the role of the intermediary goes. More on this later. Back to work. I would be really interested in any comments anyone has on their experience with intermediary design with respect to how the messages are handled. (ahhhh, Fishing).