Usign the WCF-NetMsmq adapter
I got some interesting comments on my recent post about the differences between the MSMQ and WCF-NetMSMQ BizTalk Server adapters from a developer perspective. As I explained in that post, one of the main reasons for choosing WCF-NetMSMQ adapter over the MSMQ adapter is the possibility of having type information (a.k.a WCF contract) available at design time. Let’s take a look to a practical example.
Assume that we have the following orchestration that adds two numbers. One of my friends likes to say that is the most inefficient name to add two numbers; but is great for a demo though.
Figure 1: BizTalk Orchestration
The orchestration is being activated thru a MSMQ message received by the WCF-NetMsmq adapter. The following picture shows the receive location configured to do so.
Figure 2: NetMsmq Receive location
The next step is to use the WCF Service Publishing Wizard to expose the orchestration as a WCF Service. One of the main steps in this process is to point the Wizard to a configured receive location in order to generate the correct binding information.
Figure 3: WCF Publishing Wizard: NetMsmq binding
The WSDL generated from this process looks like the following
<wsdl:definitions name="BizTalkServiceInstance" targetNamespace="http://tempuri.org/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns="http://tempuri.org/" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wsap="http://schemas.xmlsoap.org/ws/2004/08/addressing/policy" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:msc="http://schemas.microsoft.com/ws/2005/12/wsdl/contract" xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl" xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/" xmlns:wsa10="http://www.w3.org/2005/08/addressing" xmlns:wsx="http://schemas.xmlsoap.org/ws/2004/09/mex"> <wsdl:documentation> <CreationInfo Created="2007-05-03 22:02:36Z"/> </wsdl:documentation> <wsp:Policy wsu:Id="NetMsmqBinding_IOneWayAsync_policy"> <wsp:ExactlyOne> <wsp:All> <msb:BinaryEncoding xmlns:msb="http://schemas.microsoft.com/ws/06/2004/mspolicy/netbinary1"/> <msmq:MsmqVolatile xmlns:msmq="http://schemas.microsoft.com/ws/06/2004/mspolicy/msmq"/> <msmq:MsmqBestEffort xmlns:msmq="http://schemas.microsoft.com/ws/06/2004/mspolicy/msmq"/> <wsaw:UsingAddressing/> </wsp:All> </wsp:ExactlyOne> </wsp:Policy> <wsdl:types> <xsd:schema targetNamespace="http://tempuri.org/Imports"> <xsd:import schemaLocation="http://r2:80/BtsMathService/BtsMathService_MainProcess_InPort.svc?xsd=xsd2" namespace="http://BtsMathService.InputType"/> </xsd:schema> </wsdl:types> <wsdl:message name="BtsMathService_MainProcess_InPort_Operation_1_InputMessage"> <wsdl:part name="part" element="q1:Root" xmlns:q1="http://BtsMathService.InputType"/> </wsdl:message> <wsdl:portType name="BtsMathService_MainProcess_InPort"> <wsdl:documentation>service "BtsMathService.MainProcess" port "InPort"</wsdl:documentation> <wsdl:operation name="Operation_1"> <wsdl:documentation>operation "Operation_1"</wsdl:documentation> <wsdl:input message="tns:BtsMathService_MainProcess_InPort_Operation_1_InputMessage"/> </wsdl:operation> </wsdl:portType> <wsdl:binding name="NetMsmqBinding_IOneWayAsync" type="tns:BtsMathService_MainProcess_InPort"> <wsp:PolicyReference URI="#NetMsmqBinding_IOneWayAsync_policy"/> <soap12:binding transport="http://schemas.microsoft.com/soap/msmq"/> <wsdl:operation name="Operation_1"> <wsdl:documentation>operation "Operation_1"</wsdl:documentation> <soap12:operation soapAction="Operation_1" style="document"/> <wsdl:input> <soap12:body use="literal" encodingStyle="http://www.w3.org/2003/05/soap-encoding"/> </wsdl:input> </wsdl:operation> </wsdl:binding> <wsdl:service name="BizTalkServiceInstance"> <wsdl:port name="NetMsmqBinding_IOneWayAsync" binding="tns:NetMsmqBinding_IOneWayAsync"> <wsdl:documentation>net.msmq://server/private/testqueue</wsdl:documentation> <soap12:address location="net.msmq://r2/private/testqueue"/> <wsa10:EndpointReference> <wsa10:Address>net.msmq://server/private/testqueue</wsa10:Address> </wsa10:EndpointReference> </wsdl:port> </wsdl:service> </wsdl:definitions> |
Now we are ready to implement the client code. This process is not different of implementing any WCF client mainly because THE TYPE INFORMATION IS AVAILABLE AT DESIGN TIME.
BtsMathService_MainProcess_InPortClient proxy = new BtsMathService_MainProcess_InPortClient(); Root request= new Root(); request.param1= 12; request.param2= 45; proxy.Operation_1(request); |
The msmq interactions are configured at the binding level.
<?xml version="1.0" encoding="utf-8"?> <configuration> <system.serviceModel> <bindings> <netMsmqBinding> <binding name="NetMsmqBinding_IOneWayAsync"> <security mode="None"> <transport msmqAuthenticationMode="WindowsDomain" msmqEncryptionAlgorithm="RC4Stream" msmqProtectionLevel="Sign" msmqSecureHashAlgorithm="Sha1" /> <message clientCredentialType="Windows" /> </security> </binding> </netMsmqBinding> </bindings> <client> <endpoint address="net.msmq://server/private/testqueue" binding="netMsmqBinding" bindingConfiguration="NetMsmqBinding_IOneWayAsync" contract="BtsMathService_MainProcess_InPort" name="NetMsmqBinding_IOneWayAsync" /> </client> </system.serviceModel> </configuration> |
Having the contract information available at design time facilitate the interactions for products that are completely type dependant such as, surprise surprise, BizTalk Server!!! It also removes the knowledge dependency between the message sender and the receiver. But the most important factor is that this apporach uses Msmq where is should be used, at the transport level, and not impacting directly the business logic.