Let's build a simple service in BizTalk using a classic banking scenario - fund transfers in and out of accounts, along with retrieval of basic customer information. To follow along, you'll need to have BizTalk Server 2006 R2 installed and configured. We'll go through the following steps to create our service:

1. Create a BizTalk project to hold our artifacts
2. Create XML Schemas to represent data structures
3. Create XML Schemas to represent service operation messages
4. Create simple orchestrations to carry out the service operations
5. Publish the service as a Web Service using WCF
6. Publish the service as a TCP endpoint

Step 1: Create a BizTalk project
I normally recommend creating separate BizTalk projects to hold maps, orchestrations, schemas, etc., but for this example we'll just create a single BizTalk project called BankAccountService. It will hold a number of XML Schema files and two orchestration files.

First, since assemblies for BizTalk are placed in the Global Assembly Cache (GAC), we need to create a strong-name key file:

1. In Windows Explorer, create a folder to hold the service project files.
2. From the Start menu, locate and expand the "Microsoft Visual Studio 2005" folder then expand the "Visual Studio Tools" folder and choose "Visual Studio 2005 Command Prompt."
3. Change the current directory to the one that you created in Step 1 (cd "<folder path>").
4. Create a new key file using the sn.exe utility (sn -k BankAccountService.snk).

Next, we can create the project and get started:

1. Start up Visual Studio 2005
2. From the File menu, choose New then choose Project. Locate and select "BizTalk Projects," "Empty BizTalk Server Project."
3. Type "BankAccountService" into the Name textbox and specify the location for the service project files in the Location textbox (the folder created earlier).
4. When you're comfortable with the selected settings, click the OK button to create a new solution file and the BankAccountService BizTalk project.
5. Right-click the BankAccountService project in the Solution Explorer and choose Properties, then expand the "Configuration Properties," "Deployment" tree node.
6. Select "All Configurations" from the Configuration drop-down at the top of the dialog box.
7. Type "BankAccountService" into the "Application Name" textbox. When we deploy the application, this will create a new BizTalk application - a container for schemas, ports, orchestrations, etc. - for our service.
8. Expand the "Common Properties," "Assembly" tree node and locate the "Assembly Key File" setting in the properties grid. Click the "..." button and browse to and select the BankAccountService.snk file that you created earlier. Click the Open button to select the key file. This will cause our assembly to be strong-named at compile-time.
9. Finally, click OK to close the Properties dialog box. Build the solution with the Build menu, "Build Solution" menu item, and verify that the build was successful.

Step 2: Create XML Schemas to represent data structures
One of the big benefits of contract-first design is that it forces you to consider the data structures and patterns of interaction with the service right out of the gate. In our banking scenario, we will focus on the simple situations of putting money into an account or taking it out and retrieval of basic customer data. As in object-oriented design, we can readily identify a couple of entities relevant to our scenario: Customer and Account. In this case, these entities will be data structures defined in XSD as having no behavior, similar to "data transfer objects" in coding terms.

Let's go ahead and create our Account entity schema:

1. With the BankAccountService solution open, right-click the BankAccountService project and choose the Add menu then "New Item..." Select the "Schema Files" tree node and then the "Schema" item in the right-hand pane. Type the name "Account.xsd" in the Name textbox then click the Add button to create the schema file.
2. The new schema file opens automatically in the BizTalk Editor, an XML Schema editor. In most cases you will want to customize the target namespace, but for this example we will keep the default of "http://BankAccountService.Account."
3. In the left-hand pane of the Editor, select the default root node called "Root." Press F2 to enter editing mode, and type the new node name "Account", then press Enter.
4. Now let's add some data structures to the Account. Right-click the Account node and select the "Insert Schema Node," "Child Field Element" menu item. The new node appears already in edit mode, so just type the name "AccountNumber" and press Enter. We will keep the default data type of xs:string, which you can see in the Properties grid (right-click the AccountNumber node and select Properties).
5. Repeat the steps in Step 4 to add another element called "AccountType."

That's enough for our very simple Account. Now let's create our Customer entity schema. Follow Steps 1-4 again using the file name "Customer.xsd," root node name "Customer," and child field elements "CustomerID" and "LastName."

For our demo, we don't need any more detail. You may be wondering why we're even creating these schemas for so few data elements. Imagine enhancing the service with a full implementation of customer and account retrieval. These operations would use these same entity schemas, but would add many additional data elements such as AccountName, Balance, MailingAddress, and so on. Eventually you'd fill out these skinny schemas into full-blown entities with dozens of data elements.

At this point we've defined the layout of elements Account and Customer, with the specific sequences of child elements nested within. This is represented in the XSD as an <xs:element> node with an <xs:complexType> node nested within. We would prefer to make these structure definitions into reusable types so that we can easily create new elements with the same structures. This is equivalent in code to creating a class called Account or Customer and then creating multiple strongly typed instances of it.

To convert our new Account definition to a reusable type:

1. Select the Account node.
2. In the Properties window you will find a list of properties that apply to the entire element. Locate the property named "Data Structure Type." By default it has no value.
3. Enter the name "Account" in the "Data Structure Type" value and press Enter.
4. Now, if you observe the schema definition you will find that the entire <xs:complexType> that defines the structure of Account is no longer nested, but is a peer to the <xs:element> node. The <xs:element> node now contains a "type" attribute that references the complex type (also called Account). The Account type is now easily reusable by other schemas.

Repeat these four steps to make the Customer type reusable. Finally, build the solution with the Build menu, "Build Solution" menu item, and verify that the build was successful.