Using the BTS 2006 SOAP adapter without orchestrations

For me, one of the compelling uses of BizTalk is as a SOAP intermediary or as a "connector" between SOAP and other not-so-common transports/protocols. This gives you the power of the BTS pub/sub architecture and the transformation engine at the heart of your SOAP systems. You typically accomplish this by using the SOAP adapter as an on/off-ramp to the Message Box.

 

On the receive side, you can generate a SOAP receive location and the corresponding ASMX code using the "Publish schema as Web Service" option of the WS publishing wizard. This gives you a simple SOAP on-ramp to the Message Box and does not require any orchestration logic.

 

On the send side, however, there's no way to use a SOAP send port without an orchestration, leaving messaging-only scenarios out in the cold. At least not with BTS 2004 and the built-in SOAP adapter. The WSE 2.0 adapter came to the rescue and made it possible to use WSE send ports without orchestrations, although it typically required a specialized pipeline component to set up the WS-Addressing headers before dispatching. I showed a demo of this approach at TechEd this year.

 

Now for the good news. In BTS 2006, you can accomplish the same thing with the built-in SOAP adapter without too many headaches. You'll notice a new tab on the SOAP adapter properties page called "Web Service", which looks like this:

 

 

You specify an assembly that contains a Web service proxy class (typically generated via Add Web Reference) and choose a method. The assembly needs to be in the GAC. The SOAP adapter will then use this proxy/method to send the message out via SOAP. The adapter will take the message it receives from BizTalk, deserialize it into objects, and invoke the proxy method.

 

The trickiest thing about making this work is getting the message is in the right format for the proxy. I pulled my hair out yesterday trying this with proxy classes that used default "wrapped" technique with a parameter list of simple types. After talking it over with Matt and Jon about the other night, we concluded that it's probably because the adapter is expecting a multipart message in that case, which I wasn't providing. However, if your proxy takes a single complex input type, which maps directly to the XML message coming in, it seems to work every time. If you always use doc/lit/bare for your WebMethods you'll be good.

 

It's a beautiful thing to be able to wire-up BizTalk on either side of a SOAP exchange because it gives you tools for dealing with versioning (maps), multicasting (pub/sub), and numerous permutations of transport protocol/data format transitioning (adapters/pipelines). And since it no longer requires the OE, the bar just got a lot lower for mixing SOAP in with BTS 2006.