Exposing WCF services from schemas

In the previous section, we looked at accepting a new product order in an orchestration and returning a response to the submitter. What if we only want a one-way channel and want multiple consumers to subscribe to this new order? This screams for a more event-driven scenario where the publisher asynchronously sends data that is handled and acted upon by unknown downstream systems (for example, fulfillment systems and billing systems). In this case, we aren't interested in creating an orchestration that dictates our service contract but rather want to build a service on-ramp that simply gets data onto the message bus.

For this scenario, we will do the following:

• Configure a TCP endpoint in BizTalk Server
• Generate a WCF metadata service hosted in IIS that clients use to discover the service and its true service URI
• Build the metadata endpoint using only schemas and no orchestrations

We will reuse the previously built NewOrder_XML.xsd schema as the input message to the new service. This means that this new scenario requires no new development on our part. The scenario begins with the creation of a new receive port and location in the BizTalkSOA.Chapter3 application found in the BizTalk Administration Console. The receive port has the following attributes:

Once the receive location is created, it should be started to ensure that it was configured correctly. An example of an incorrect configuration would be the designation of a URI port that was already in use by other processes. If this situation occurs, a message is added to the Application Event Log explaining the port collision.

Now, as we mentioned before, BizTalk receive locations are never associated with a particular XSD schema. So, if we are assuming that our service client(s) does not have a copy of the service contract already, then we must provide a metadata endpoint that explains the type of message that our in-process receive location expects. In the previous section, we saw that the WCF endpoints generated from BizTalk orchestrations have verbose descriptions and burden you with lengthy attribute names. In many cases, you will want more fine-grained control over the service definition than what the Publish BizTalk orchestrations as WCF service selection in the BizTalk WCF Service Publishing Wizard can give you. In fact, unless you are desperate for the quickest possible way to generate WCF services and/or descriptions, there is no discernible reason to ever choose the Publish BizTalk orchestrations as WCF service option.

The alternative to using orchestrations to define the service contract and communication pattern is to build up the service definition graphically using a schema-only model. Selecting this alternative option allows us to manually name the service, choose a communication pattern, name the service operation, and choose the data contract(s).

To create such an endpoint, fire up the BizTalk WCF Service Publishing Wizard once again and choose Metadata only endpoint (MEX) as WCF Service Type. When we are asked which receive location we wish to produce metadata for, select BizTalkSOA.Chapter3.ReceiveNewOrder and click Next; and also click Next on the AppFabric Connect screen. After choosing Publish schemas as WCF service on the next screen of the wizard, we are given the opportunity to manually describe the new service.

Here, we apply friendlier names for service attributes, starting with the service description at the top. Note that this attribute cannot have dot operators in the name, so I called it BizTalkSOAChapter3. This value does not show up anywhere in the service itself but rather is the name of the Visual Studio solution file that the wizard generates for the web service. After renaming the service node OrderService, the existing two-way operation should be deleted. Next, add a new operation by right-clicking on the service, selecting Add web method, and choosing a one-way operation. After changing the operation name to SubmitNewOrder, we need to right-click on the Request message and choose Select schema type. This is where we indicate the input message type that our service expects. Browse to the appropriate BizTalk project assembly and pick the NewOrder_XML schema. Our service definition will now look like this:

On the next page of the wizard, set the service namespace to http://BizTalkSOA.Chapter3/Service. For the service location, I chose http://localhost/BizTalkSOA.Chapter3.OrderManagement.BizTalkMEX. Once the wizard is completed, we have an IIS-deployed metadata endpoint that can be interrogated by WCF clients to reveal the contract and URL for our BizTalk-hosted service. Note that the status of the actual BizTalk endpoint (that is, whether the receive location is enabled or disabled) does not impact the availability of the MEX endpoint.