After my mini-rant on WCF last week, I figured that my only course of action was to spend a bit of my free time actually re-learning WCF (+ BizTalk) and building out the scenarios that most interest me.
In my effort to move my WCF skill set from “able to talk about it” to “somewhat dangerous”, I built each of the following scenarios:
|Service hosted in Windows Form (HTTP)||Pretty simple to build the service contract, and use operations made up of simple types and complex types (using [DataContract]). Fairly straightforward to modify the app.config used by the WinForm host to hold the Http endpoint (and provide metadata support). Screwed around with various metadata options for a while, and found this blog post on metadata publication options quite useful during my adventures. To consume the service, I used svcutil.exe to build the message, client objects and sample configuration file. Decided to call the service using the client vs. going directly at the ChannelFactory.|
|Service hosted in Windows Form (TCP)||Liked that the ServiceHost class automatically loads up all the endpoints in the host configuration. No need to explicitly “start” each one. Don’t love that by default, the generated configuration file (from svcutil.exe) uses the same identifier for the bindingConfiguration and name values. This mixed me up for a second, so I’ve taken to changing the name value to something very specific.|
|Service hosted in IIS||I don’t learn well by “copy/paste” scenarios, but I DO like having a reference model to compare against. That said, this post on hosting WCF services in IIS is quite useful to use as a guide. Deploying to IIS was easier than I expected. My previous opinion that setting up WCF services takes too many steps must have been a result of getting burned by an early build of Indigo.|
|Service generated by BizTalk (WSHttp) and hosted in IIS||BizTalk WCF Wizard is fairly solid. Deployed a new WSHttp service to IIS, used svcutil.exe to build the necessary consuming components, and ripped out the bits from the generated configuration file and added them to my existing “WCF Consumer” application. See the steps below which I followed to get my BizTalk-generated service ready to run.|
|Service Generated By BizTalk (TCP) and hosted in BizTalk||I added a receive location to the receive port generated by the WCF Wizard in the scenario above. I then walked through the WCF Wizard again, this time creating a MEX endpoint in IIS to provide the contract/channel information for the service consumer. As expected (but still neat to see), the endpoint in the app.config generated by svcutil.exe had the actual TCP endpoint stored, not the MEX endpoint in IIS. Of course that’s how it’s supposed to work, but I’m easily amused. I was able to call this service using identical code (except for the endpoint configuration name) as the WSHttp BizTalk service.|
|Service Generated by BizTalk (WSHttp) and hosted in BizTalk||This excites me a bit. Hosting my web service in process without needing to use IIS. I plan on exploring this scenario much more to identify how handling is different on an in-process hosted web service vs. an IIS hosted on (how exceptions are handled, security configuration, load balancing). To make this work, I created yet another receive location on the above created receive port, set the adapter as WCF-Custom and chose the WS-Http binding. I also added a metadata behavior in case I wanted to generate any bits using svcutil.exe. Instead of generating any new bits, I simply added an endpoint to my configuration file while reusing the same binding, bindingConfiguration and contract as my other WsHttp service. After switching my code to use this new endpoint configuration, everything processed successfully.|
|Consuming basicHttp WCF service via classic “add web reference”||This was my “backwards compatible” test. Could I build a fancy WCF service that my non-WCF clients could consume easily? If I charge forward with WCF, do I risk screwing up the plethora of systems that use SOAP Basic Profile 1.1 as their web interface? My WCF service provided a basicHttp binding in addition to more robust binding options. In Visual Studio.NET I did an “add web reference” and attempted to use this WCF service as I would a “classic” SOAP service. And … it worked perfectly. So it shouldn’t matter if a sizable part of my organization can’t utilize WS* features in the near future. I can still “downgrade” services for their consumption, while providing next-level capabilities to clients that support it.|
I’ve got a few more scenarios queued up (UriTemplates, security configurations, transactions and reliable sessions), but so far, things are looking good. My wall of skepticism is slowly crumbling.
That said, I still had a bit of work to first get all this running. First off, I got the dreaded plain text shows up when browsing the svc file issue. I reinstalled .NET Framework 3.0 and reassociated it with IIS and it appears that this cleared things up. However, after first walking through the BizTalk WCF Publishing Wizard, I got the following page upon browsing the generated IIS-hosted web service:
Ok, next step was to add <customErrors mode=”Off”/> to the web.config file. This now resulted in this error:
Once again, SharePoint screws me up. If you’ve got SharePoint on the box, you need to add <trust level=”Full” originUrl=”” /> to your web.config file. In fairness, this is mentioned in the BizTalk walkthrough as a “note”. After adding this setting, I now got this message:
That’s cool. The WSHttpWebServiceHostFactory used by the service is in tune with the BizTalk configuration, so it knows the receive location is currently disabled. Once I enable the receive location, I get this:
All in all, a nice experience. A bit of trial and error to get things right, but that’s the best way to learn, right?