Поделиться через

Using Only BizTalk Messaging With Request/Response On Both Ends

  • Статья

So is BizTalk *really* smart enough to allow me to do request/response operations on both sides of my process without an orchestration in the middle? I set out to prove this scenario out for myself and wanted to share the results.

I want to see if I can create a web service input into BizTalk, and have that request message trigger a request/response send port, and then take the response of that send port, and match it back to the response message of the original call. Make sense? So ...

  1. Call synchronous web service that publishes a message into BizTalk
  2. Take that input message and then route to a send port which in turn calls out to an external web service
  3. Accept that response of that web service call
  4. Route that response back to the initial caller

For this to happen, this would mean that BizTalk is able hold onto that initial calling thread, even as processing potentially hops physical machines, application boundaries and the like.

First, you'll see my web service below. It doesn't do much. Takes a "customer" in, changes the customer name a bit, returns the same customer type back.

Then I added a web reference to my project so that I'd get the web message types I needed.

Next, I needed two maps. One to go from the "customer" passed into the BizTalk web service to the format expected by the service called by the send port. And, then a map to handle the reverse scenario (mapping the result of the send port's service call back to the format of the initial caller).

Then comes the ports. First, the receive location for the BizTalk-generated web service (which was built by generating a service out of schemas directly). This receive location does XML pipelines in both directions, and the receive port applies both the inbound and outbound mapping.

The send port also does XML pipelines both directions. I used the new functionality in BizTalk Server 2006 which allows me to call a web service directly without using an orchestration. In my case, I referenced my BizTalk assembly, and because I added a web reference to my external service, I have the proxy class needed to call my web method.

Now the moment of truth. I created a client app that calls the service. And, to make sure that the correct response finds its way back to the correct thread, I opened a couple instances of the client tool at once. After submitting web service requests from both simultaneously, I did indeed receive the correct message back to each client.

So how the heck does this work? The End Point Manager (EPM) actually maintains subscriptions for the response message (which you can see if you're really quick on the "run query" button). These subscriptions allow the EPM to grab the response message from the send port and correlate it back to the response message of the initial caller. I'm actually *really* impressed that this works. That's fairly brainy stuff.

Technorati Tags: BizTalk, Web Services

Comments

  • Anonymous
    December 06, 2006
    The comment has been removed
  • Anonymous
    December 06, 2006
    The comment has been removed