After my post of various WCF scenarios, I received a couple questions about using the in-process host to receive WCF HTTP requests, so I thought I’d briefly show my configuration setup for making this work.
First off, I had created a “regular” IIS-hosted WCF web service and auto-generated a receive port and location. I decided to reuse that receive port, and created a new receive location for my in-process HTTP receive. I used the WCF-Custom adapter, which as you can see, runs only within an in-process host.
The first adapter configuration tab is where you identify the endpoint URL. This value is completely made-up. I chose an unused port (8910), and then created my desired URL.
Next, on the Binding tab, I set the wsHttpBinding as the desired type.
Next, I added a behavior for “serviceMetadata” to allow for easy discovery of my service contract.
That’s it for the receive location configuration. I need to enable the receive location in order to instantiate the WCF service host. If I try to browse to my service URL while the location is disabled, I get a “page cannot be displayed” error. Once I enable the location, and hit my made-up URL in the browser, I can see the service description. Note that if I had not created the serviceMetadata behavior, I would have received a “Metadata publishing for this service is currently disabled.” message when viewing my service in the browser.
So, now I can generate the necessary client-side objects and configuration to call this service. My client application’s configuration file has the following endpoint entry:
<endpoint
address="http://localhost:8910/incidentreporting/incident.svc"
binding="wsHttpBinding"
bindingConfiguration="WSHttpBinding_ITwoWayAsyncVoid"
contract="Service1" name="IncidentInProcSvc">
<identity>
<userPrincipalName value="myserver\user123" />
</identity>
</endpoint>
You’ll notice my endpoint address matches the value in the receive location, and an “identity” node exists because my service configuration (in the receive location) identified clientCredentialType as “Windows” for message/transport security.
There you go. Pretty easy to “build” a service that is hosted within the BizTalk process, completely bypassing IIS, and leave the service consumer none the wiser.
UPDATE: You may notice that nowhere above did I build a contract into the service itself. I reused a contract in my client endpoint, but how would the service consumer know what to send to my service? This is probably where you’d decide to create a MEX endpoint. You’d point at the WS-Custom receive location in the WCF Publishing Wizard, and choose a schema(s) to represent the contract. Then users would point to the MEX service to generate their strongly-typed client components.
Richard Seroter's Architecture Musings 
Leave a reply to Nico Cancel reply