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:
| Scenario | Comments |
| 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?
Richard Seroter's Architecture Musings 
Not bad! I think now you’ve driven this thing around the blog more than I have.
Even if you’re sticking with SOAP and base profile web services for your non-BizTalk services being created, I see a real advantage to building them in WCF instead of using a basic ASMX web serivce, because it’ll allow you to just hang another protocol off of the same channel later on if you decide to.
That, and this is really the direction everything is going with Microsoft it seems, so I might as well learn it sooner than later. It’s helpful since I’m expected to be able to talk about it, I suppose. 🙂
For example, instead of building BizTalk-specific line of business (LOB) adapters, Microsoft is building them all using the WCF LOB Adapter SDK, which you can then consume from BizTalk using the WCF-Custom adapter, or you can skip BizTalk altogether and use the service from any application able to consume WCF. Nifty!
Wow… funny type-o. I meant to say “driven around the block” but I guess “blog” works too (though since I seldom blog…). 😛
What would be your recommendation around Isolated vs In-Process? Any difference?
Hey Ryan. I’ve liked using the In-Process model for the control it gives me, so you have to decide whether the IIS features (isolated host) offer something you want that a BizTalk-managed process can’t provide. Could be around security / access control, ISAPI filters that do things like service mediation, centralized web management, etc. In those cases, IIS might be best.
Richard,
thanks for the insights. yeah i’m going with InProcess for now. i guess it wouldn’t be that hard to switch to Isloated later if we found we had the need.