Request-Response to Solicit-Response without Using an Orchestration

At a client site where we use BizTalk Server 2009 I was asked to expose a few SQL Server views so they could be accessible through WCF web services. I could easily have solved this by putting the integration logic in orchestrations where the implementation would have looked something like this:

• use the caller’s incoming request message to invoke an orchestration.
• in the orchestration use a map to transform the request message to a message format that is used to call a solicit-response send port.
• when the response from SQL Server comes back, use another map in the orchestration to transform the response message to an appropriate message format that will be sent back to the original caller. 

Easy and quick, build the orchestration, deploy it to BizTalk and use the BizTalk WCF Service Publishing Wizard to expose the orchestration as a WCF endpoint. 


However it just didn’t feel right. I wasn’t going to have any long running transactions and I wasn’t going to invoke several systems for a single request, so I wanted to avoid using orchestrations. An orchestration approach would mean multiple round trips to the MessageBox to publish and consume messages to/from the BizTalkMsgBoxDb and to hydrate and dehydrate the state of the orchestration. All these operations come at a cost.


In a messaging only scenarios like this an alternative approach is to move the logic to receive and send ports to reduce the amount of round trips to the BizTalkMsgBoxDb which consequently increases throughput and reduces latency of the application.


I did some research on the web on how to implement a request-response receive coupled to a solicit-response send without using an orchestration but to my surprise I didn’t come across any good samples. If you ever find yourself faced with a similar problem here are the steps necessary to implement a best practices solution:

1. Start by launching the BizTalk WCF Service Publishing Wizard.
2. In the wizard choose to generate a Service Endpoint, specify your binding of choice and choose to create a BizTalk receive location for the endpoint. Also choose to generate a metadata endpoint so that clients can consume the contract for the receive location.
3. Next step is important, it is here where we’ll tell the wizard that it should publish a schema as a WCF service as opposed to publishing an orchestration.
4. On the next screen we have the option to name the service and its operation. We’ll then have to choose a schema for the Request message and a schema for the Response message.
5. Finally we’ll specify a target namespace for the service and a location for it to be deployed.
6. Once the wizard completes a WCF endpoint is deployed to IIS and a receive location created in BizTalk.
7. We also need to set up the send side of the solution. This can be done by creating a solicit-response WCF SQL send port in the BizTalk Server Administration Console.
8. Use an appropriate filter as subscription in the send port, for instance BTS.MessageType.
9. The final step is to set an outbound map and an inbound map on the send port. The outbound map will transform the message from the caller to a SQL Server request while the inbound map transforms the SQL Server response to the message format that is going back to the caller. Essentially these are the same maps that we would use in an orchestration approach.

The end result is a WCF request-response endpoint that clients call to submit a message and receive a response. Incoming messages are picked up by a subscribing solicit-response send port which correlates back the result of its operation to the client without an orchestration in the middle.