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 talked 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 discernable 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, once again fire up the BizTalk WCF Service Publishing
Wizard and choose the Metadata only endpoint (MEX) as the WCF Service Type. When we
are asked which receive location we wish to produce metadata for, select the
Seroter.BizTalkSOA.Chapter3.ReceiveNewOrder.WcfTcp location. After choosing to
Publish schemas as WCF service on the next wizard page, 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 SeroterBizTalkSOAChapter3. This value does NOT show up
anywhere in the service itself, but is rather the name of the Visual Studio.NET
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,
a new operation is added by right-clicking the service, selecting Add web method,
and choosing a one-way operation. After changing the operation name to
SubmitNewOrder, we need to right-click the Request message and choose to 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 only
available schema type. Our service definition would now look like this: