Here's the situation: I've a stateless web app that uses jQuery to hit another application that's just a set of services.  I chose this model because I wanted to separate out the user interaction code from the information interface - the services simply give out data upon request and the UI allows the user to interact with it enough to make calls to the service interface.  Seems rational, simple and clean.

I chose WCF for the service layer and began playing around.  I'm a rather late adopter in learning WCF, primarily because it seemed so heavyweight.  Wrapping all sorts of communications methodologies into one sounded fairly ambitious.  To do a simple thing like return XML or JSON, there're a lot of pieces that need to be put in place: interfaces, somewhat arcane attributes - good practices, mind you with encapsulation of the attributes and the use of interfaces - but this could all be done and simpler with good old asmx's.  Once ASP.NET MVC came along, most of the web-facing usage for WCF is pretty much trumped and made obsolete.  Regardless, I persisted and made a nice front end UI with jQuery that posted json info to the WCF services and received json back.  All's well and good.

The problem comes in putting WCF on IIS7 in what I call development and production modes or, as other people have envisoned using it, in internal and external modes.  Another example scenario is URI aggregation and forwarding for a SOA scenario.  I have external responses on 80, but I want internal service traffic to occur on a different port.

My IIS was configured to respond to dev:80 and dev:8080.  Seems to respond ok when I hit localhost:80 or localhost:8080, but I receive a "This collection already contains an address with scheme http.  There can be at most one address per scheme in this collection.Parameter name: item" error when trying to go to dev:8080.

Looking around, the post "Can't host WCF service in a website with multiple identities" at Microsoft Connect sums it up nicely: Microsoft's aware of this issue posted by a user and closes the issue without a fix, calling the behavior "by design." To be fair, they changed the bug's status to "Closed as Fixed" without providing a fix.  (Like "hotfix" - neither hot nor a fix.)  Eventually in the comments on this bug they state that this issue is fixed in .NET 4.0 beta 2.  Great, that's what, WCF 3.0?  (or 3.0, if .NET 3.5 was 2.0).

Internally, I can run my application quite well, but users outside my network can't access it.  Either I put up two copies of the service (ugh) or I consolidate my service on one port.

I've come away thinking that I want that part of my brain back that is stuffed with knowing anything about WCF.

Here's my cynical opinion about it (aka hating). WCF comes out of Microsoft's "enlightenment, wave 2" attitude, after they'd finally adopted an OO methodology with .NET, where they appeared to be in such a tizzy that they slapped on some skis, got in a pool and proceeded to jump the shark, converting all their grand unification ideas into monolithic pieces (see their much delayed ORM, Entity Framework, and the poorly executed Workflow Foundation) and half-reworks (see SharePoint 2007, CRM 4.0, BizTalk 2006 - only the pieces that were easy to veneer with .NET were done, the rest was done incompletely, leaving them looking like Matt Dillon in There's Something About Mary trying to impress).  Honestly, it works great, you just gotta know where to step.  This is sort of a typical experience I've had with Microsoft products - early adopters evangelize and late ("late 1.0") adopters get bitten - except usually it's their packaged products that suffer this malaise, not libraries so close to the core framework.  "Knowing where to step" is not expert-level services from a software framework, it's rote memorization without logic behind it

No wonder Microsoft has no native SOA offering, preferring to partner with other SOA vendors (HP/Systinet, webMethods/SAP, or SOA Software - all of whom use Java).  The multiple offerings of BizTalk / WF / WCF (in some combination / competition) are these huge elephants in the room of that space.

Phew.  Hating's hard work.

I've more or less resigned myself to consolidating services, but I intend to, immediately afterwards, rewrite the app into ASP.NET MVC which will allow me to consolidate the stateless UI project and the services project into one.