After
building and deploying this sample, we need to assemble the necessary
messaging ports from within the BizTalk Administration Console. First,
import the BizTalk WCF Service Publishing Wizard-generated binding to produce our concluding WCF-NetMsmq
adapter send port. After adding both a "message-type"-based
subscription and BizTalk map to the send port, we build a simple FILE
receive location to test our destination service. To prove that BizTalk
successfully publishes to the queue, we should turn off the IIS 7.0
application pool associated with our service so that the messages are
not automatically extracted from the queue by the service. If everything
was set up correctly, we should be able to pick up a message, and see
BizTalk drop it to the designated queue.
Now that we have BizTalk
successfully acting as a MSMQ service consumer, it's time to complete
our scenario and promote BizTalk to the status of MSMQ service provider
as well. Lucky for us, this requires no additional development
activities. Instead, we can switch our inbound receive location from
being FILE-based to WCF-NetMsmq-based. In this case, we configure the in-process adapter to point to the private queue created earlier in this section.
Because we want our
upstream service client to interrogate our BizTalk WCF endpoint for
metadata, we should generate an IIS-hosted endpoint, which reveals our
service contract. To do this, launch the BizTalk WCF Service Publishing Wizard and generate a metadata endpoint for our existing WCF-NetMsmq receive location.
Via the wizard, we want to
expose a service with a one-way operation that will publish a message to
the queue. If we are successful, a client application will be able to
reference the MEX endpoint and import all the objects and configurations
necessary to call the BizTalk hosted service. Remember that our MEX
WSDL, while hosted as an HTTP endpoint, should show a service address
that is MSMQ-based.
If you recall from earlier BizTalk + WCF discussions, we discovered that a BizTalk receive location needs to be in an Enabled
status in order for the service to be online. Once again, MSMQ is an
exception. Because there is a layer between the client and BizTalk
endpoint, our BizTalk receive location (or BizTalk itself!) can be
offline and the client application can still confidently distribute
messages to the service. Once the BizTalk receive location returns to an
active state, messages are read from the queue.
BizTalk has very strong
support for MSMQ, and in scenarios with very disconnected clients
possessing volatile uptime or specific throttling requirements, an
intermediary queue offers a convenient way to reliably transfer data
between systems.
