NOTE

---

At the time of this printing, BizTalk uses an XML Data Reduced (XDR) schema, which is slightly different from the schema defined by the current Worldwide Web Consortium (W3C) standard. The XDR schema is expected to be used until the W3C releases the final schema standard, at which time BizTalk will implement the standard schema. The differences between the two schemas will be discussed in the section "XML Data Reduced Schemas" later in this chapter.

Loosely Coupled Messages

As mentioned, the BizTalk header contains only information about the destination and source BizTalk servers. There is no information within the BizTalk document header that identifies what method or object will use this information. In other words, the BizTalk document header has no real information about the application that will process it.

It's up to the receiving BizTalk server to identify the incoming message and route it to the correct application. For example, a BizTalk server can be set up so that all messages coming from http://www.northwindtraders.com with an identity that begins with PO00123 will be passed to the new order processing object. (Identity is a child element of the properties element that will be discussed in detail later in this chapter.) The same message sent to a different company may be sent to a completely different component. These messages are called loosely coupled, meaning that they are not coupled with specific processing applications.

The delivery element is a child element of the SOAP Header element. This element includes information about the message such as the source and destination systems. The delivery element identifies where the message has come from and where it is going and gives routing and other supporting information. This element is required and can appear only once. The delivery element contains three child elements: to, from, and reliability. The to and from elements are required. All three elements can appear only once.

The to and from elements

As mentioned previously, both the to and from elements are child elements of the delivery element. Both of these elements contain one child element: address. The address child element is required and can occur only once. The address child element can specify any business entity, such as a URI or a department or organization name. For the to element, the address element contains the business entity for the receiving BizTalk server. For the from element, the address element contains the business entity for the sending BizTalk server. URIs can include prefixes such as http:// that specify the means of transport for a message. You can include a prefix, or you can leave it out and let the BizTalk server resolve the specific address system. If you omit the prefix, the URI is called a logical identifier.

The address element also has a required xsi:type attribute. This attribute signifies the category of the address and determines the structure of the address content. The following code shows an example of a to element and a from element:

<dlv:delivery SOAP-ENV:mustUnderstand="1" xmlns:dlv="http://schema.biztalk.org/btf-2-0/delivery" xmlns:agr="uri/of/agreement">    <dlv:to>       <dlv:address xsi:type="agr:URIDestination">           http://www.northwindtraders.com/PO.asp/Billing       </dlv:address>    </dlv:to>    <dlv:from>       <dlv:address xsi:type="agr:department">           Orders          </dlv:address>    </dlv:from> </dlv:delivery>

This document uses two different types of addresses: the first is a URI and the second is a department type. The BizTalk server can identify these two types of addresses.

The reliability element

The reliability element is optional and contains information that can help guarantee reliable delivery of the BizTalk document. When the reliability element is present, the BizTalk server that receives the message must send a message back to the sending BizTalk server using the URI. This process will be discussed in more detail in the section "Receipt documents" below.

The reliability element has two mandatory elements that can occur only once each: confirmTo and receiptRequiredBy. The confirmTo element contains the URL that specifies the transport address to which the receipt will be sent. The receiptRequiredBy element contains a time instant that specifies the absolute time by which the BizTalk message must be received. The content of this element should be formatted according to the International Standard ISO 8601; refer to http://www.cl.cam.ac.uk/~mgk25/iso-time.html for more information about this standard. All times in the BizTalk header will use the ISO 8601 standard. The following code shows an example of a reliability element:

<dlv:reliability>    <dlv:confirmTo>www.northwindtraders.com/poConfirm    </dlv:confirmTo>    <dlv:receiptRequiredBy>       2300-05-44T03:00:00+09:00    </dlv:receiptRequiredBy> </dlv:reliability>

If the receipt is not received within a specified period of time, the sending BFC server can attempt to resend the message. If the recipient BFC server gets the message two or more times, the identity element of the properties element can be used to eliminate duplicates of the same BizTalk document. The sending BFC server can also create a delivery failure report after a certain number of retries or when a receipt has not been received after the first attempt.

NOTE

---

There is always a small possibility that a recipient BFC server has actually received the message, but has either failed to generate the return receipt, or the return receipt has been lost. In these cases, a failure report might be generated by the sending BFC server when the message was actually sent.

Receipt documents

The receipt document is a SOAP 1.1 compliant message that must contain at least the receipt and properties elements and an empty body. The receipt is not a BizTalk document because it contains no information in its body. The content of the receipt must identify the BizTalk document being acknowledged. The receipt will contain a timestamp marking the time the BizTalk document was received. In addition, the receipt can contain elements copied directly from the BizTalk document being acknowledged.

The properties element is a child element of the SOAP Header element and provides information that can be used for identification of the BizTalk message. The section contained within this element must be understood by any BFC server before a message can be properly processed. The properties element has the following child elements: identity, sentAt, expiresAt, and topic. All of these elements are mandatory and can occur only once. An example of the properties element is shown in the following code:

<prop:properties SOAP-ENV:mustUnderstand="1"    xmlns:prop="http://schema.biztalk.org/btf-2-0/properties">    <prop:identity>uuid:00000000-0000-0000-0000-00000000001     </prop:identity>    <prop:sentAt>2300-05-14T03:00:00+09:00</prop:sentAt>    <prop:expiresAt>2300-05-44T03:00:00+09:00</prop:expiresAt>    <prop:topic>http://northwindtranders.com/PO</prop:topic> </prop:properties>

The identity element

The identity element is a URI that will uniquely identify the BizTalk document. This identity can be used for logging, tracking, error handling, or other document handling purposes. Any unique identifier can be used.

The sentAt element

The sentAt element is a timestamp for the document. The time marks the exact time the sending BFC server first attempted to transmit the document.

The expiresAt element

The expiresAt element is the time when the BizTalk message will expire. Any time beyond the time specified in the expiresAt element, the BizTalk message is considered to have expired and cannot be processed. A reasonable amount of time should be created between the time the document is created and the time specified in the expiresAt element.

The topic element

The topic element is a URI that can be used to uniquely identify the general purpose of the BizTalk message. This information has various uses, such as interest-based routing as found in a publish/subscribe arrangement.

The manifest element is a child element of the SOAP Header element; it is used to indicate which files are actually included in or associated with a BizTalk document. The manifest element is a catalog of all the documents carried in the BizTalk document. Additional files, such as images or other binary information, can be included in or with the BizTalk document. The manifest element has one required child element: reference, which can occur one or more times. An example of the manifest element is shown in the following code:

<fst:manifest xmlns:fst=    "http://schema.biztalk.org/btf-2-0/manifest">    <fst:reference fst:uri="#Purchase_Order">       <fst:description>Purchase order for Northwind       </fst:description>    </fst:reference>    <fst:reference fst:uri="CID:po.jpg@NorthwindTraders.com">       <fst:description>Scanned image of the contract       </fst:description>    </fst:reference> </fst:manifest>

The reference element

The reference child element is used to reference additional XML or non-XML files that were sent as part of the BizTalk message. These files can include content that is not carried in the BizTalk document. These files can be implemented as Multipurpose Internet Mail Extensions (MIME) parts or can be implemented through other mechanisms. MIME includes a standard set of tags that can be included within the Header section of the document. These tags can then be used to identify, attach, and send additional documents. BizTalk currently uses MIME.

NOTE

---

If you try to include binary information in your XML document as an element, you will receive errors because the binary information will have invalid characters. You can base-64 encode the binary file, which will convert all the binary information to text characters. Unfortunately, this will increase the size of the BizTalk message and might not be the best solution. You could also use multipart MIME, which is a standard format for referencing one or more nontext attachments. We'll discuss using multipart MIME later in this chapter.

The reference child element can have two child elements: uri and description. The uri is mandatory and the description is optional. Both can occur only once.

The uri child element contains a reference that can be resolved to the resource that is being referenced in the reference element. The uri can be:

• A relative URI reference in the form of #id that resolves to business documents in the SOAP Body
• A content-ID URL in the form of CID:content-ID-Value that will resolve to attachments carried as MIME parts with the BizTalk message
• A URL that will resolve to attachments that are carried as MIME parts with the BizTalk message, but outside the BizTalk document

The description element is a text description of the document that is referenced by the reference element.

The process element provides information about the business process associated with the BizTalk message. The process element has two mandatory child elements, type and instance, and one optional element, handle. All the child elements may occur only once. A process element may look as shown in the following code:

<prc:process SOAP-ENV:mustUnderstand="1"    xmlns:prc="http://schema.biztalk.org/btf-2-0/process/">    <prc:type>purchase:Food_Purchase_Order</prc:type>    <prc:instance> purchase:Food_Purchase_Order:0001    </prc:instance>    <prc:handle>port:po_app</prc:handle> </prc:process>

The type element

The type element contains a URI that defines the type of business process the BizTalk message is associated with. The type element is usually defined by two or more business partners. The type element uses a pattern that is often used in many documents. For example, the purchase of an item would be an example of a pattern.

The instance element

The instance element contains a URI reference that uniquely identifies a particular instance of the business process that a business document is associated with. For example, the type element might identify the business process as a BizTalk document of type order, whereas the instance element might identify the business process as being order number 0001. Usually, the instance element's content is created by appending a unique identifier onto the end of the type element's content as shown above.

The handle element

The handle element is an optional element that can be used to give more information that can be used to identify a process. This information can be used to identify which step the BizTalk message might be within the overall business process.

A BizTalk message can be constructed using the multipart MIME format defined in Request for Comment (RFC) 2387 (http://www.ietf.org/rfc/rfc2387.txt). To use the MIME format with an HTTP document, you need to take some special considerations. An example of a BizTalk Message in MIME format would look as shown in the code that follows.

MIME-Version: 1.0 Content-Type: Multipart/Related;         boundary=biztalk_document_boundary;         type=text/xml;         start="<po.xml@Northwindtraders.com>" Content-Description: This is the optional message description. -- biztalk_document_boundary  Content-Type: text/xml; charset=UTF-8 Content-ID: <po.xml@Northwindtraders.com> <?xml version='1.0' ?> <SOAP-ENV:Envelope     xmlns:xsi= "http://www.w3.org/1999/XMLSchema/instance"    xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope"    xsi:schemaLocation=    "http://www.northwindtraders.com/schemas/NorthwindPOSchema.xsd">    <SOAP-ENV:Header xsi:type="NorthwindHeader">    <!--BizTags begin here -->    <dlv:delivery SOAP-ENV:mustUnderstand="1"       xmlns:dlv="http://schema.biztalk.org/btf-2-0/delivery"       xmlns:agr="uri/of/agreement">     <!-- Delivery and properties header entries omitted for         brevity -->  <fst:manifest xmlns:fst=     "http://schema.biztalk.org/btf-2-0/manifest">     <fst:reference fst:uri="#Purchase_Order">        <fst:description>Ppurchase order for Northwind        </fst:description>     </fst:reference>     <fst:reference fst:uri="CID:po.jpg@Northwindtraders.com">        <fst:description>Scanned image of the contract                 </fst:description>     </fst:reference>  </fst:manifest>    <!--BizTags end here -->    </SOAP-ENV:Header>    <SOAP-ENV:Body xsi:type="NorthwindBody">       <m:UpdatePO xmlns:m=        "http://www.northwindtraders.com/schemas/NPOSchema.xsd">       <!¡ªSOAP document containing PO enclosed ends here -->    </SOAP-ENV:Body> </SOAP-ENV:Envelope> -- biztalk_document_boundary  Content-Type: image/jpeg Content-ID: <CID:po.jpg@Northwindtraders.com >    ...JPEG image... --biztalk_document_boundary

The Content-Type tag identifies this document as a Multipart MIME document. The boundary parameter defines the boundaries between different documents in the MIME document. The start parameter is required for a BizTalk message and refers to the document that will be processed first. For a BizTalk message, the start parameter will always refer to the SOAP document. The value for the start parameter should always be equal to the Content-ID tag's value for the SOAP element. The Content-ID tags are used to identify the different sections of the document and are therefore required for every section. The manifest element's child element reference uses a URI to identify the non-SOAP elements of the document. The Content-ID for these non-SOAP elements must be equal to these URIs. The SOAP document must be included in the root of the MultiPart MIME document. MIME documents can have a charset parameter, but this parameter should not be used for BizTalk messages.

As mentioned earlier in this chapter, BizTalk uses an XML Data Reduced schema. This schema and the schema currently defined by the W3C differ. Microsoft needed to build and release Internet Explorer 5, and it wanted to include an XML parser with Internet Explorer 5 that would work with schemas. Unfortunately, the W3C schema standard was not completed at the time Microsoft was developing Internet Explorer 5. Therefore, Microsoft used the temporary schema XDR. The XDR schema is based on a 1998 proposal to the W3C and can be found at http://www.w3.org/TR/1998/NOTE-XML-data-0105. Many similarities exist in the XDR and the W3C schemas, but there are also differences. The primary difference is that the two schemas use different keywords and XDR has less functionality.

The following code shows a sample DTD for the BizTalk schema.

<!ENTITY % dataTypes "(bin.base64 | bin.hex | boolean | char |    date | dateTime | dateTime.tz |fixed.14.4 | float | int |    number | time | time.tz | i1 | i2 | i4 | r4 | r8 | ui1 | ui2 |    ui4 |uri | uuid | entity | entities | enumeration | id | idref |    idrefs | nmtoken | nmtokens | notation | string)"> <!ENTITY % elementNamespace "urn:schemas-microsoft-com:xml-data"> <!ENTITY % dataNamespace "urn:schemas-microsoft-com:datatypes"> <!ELEMENT Schema  (AttributeType+, ElementType+, description)> <!ATTLIST Schema  xmlns CDATA  %elementNamespace;                   xmlns:dt    CDATA  %dataNamespace;                   name     CDATA  #REQUIRED > <!ELEMENT ElementType  (AttributeType, attribute, element+,                           datatype, description, group)> <!ATTLIST ElementType  order    (one | seq | many)  many           content  (empty | textOnly | eltOnly | mixed)  mixed           dt:type    %dataTypes;  #IMPLIED           model (open | closed) open           name    ID  #REQUIRED > <!ELEMENT AttributeType  (datatype, description)> <!ATTLIST AttributeType             name         ID   #REQUIRED           default     CDATA  #REQUIRED           dt:type  (entity | entities | enumeration | id | idref |           idrefs | nmtoken | nmtokens | notation | string) #IMPLIED           dt:values CDATA #IMPLIED           required (yes | no) #IMPLIED > <!ELEMENT attribute  (description)> <!ATTLIST attribute  type CDATA  #REQUIRED           default CDATA #IMPLIED           required (yes | no) #IMPLIED> <!ELEMENT element  (description)> <!ATTLIST element  type CDATA  #REQUIRED           minOccurs (0 | 1) #IMPLIED           maxOccurs  (1 | *) #IMPLIED> <!ELEMENT description () #PCDATA> <!ELEMENT datatype ()> <!ATTLIST datatype           dt:type %dataTypes; #REQUIRED> <!ELEMENT group(element, description)> <!ATTLIST group           order (one | seq | many) #REQUIRED           minOccurs (0 | 1)  1           maxOccurs  (1 | *)  1>

Let's look at each of the elements contained in BizTalk schemas and see how they are used.

A description element can be used in an AttributeType, an ElementType, a Schema, a group, an element, or an attribute element. The description element contains a description of the element. A typical description element might look like this:

<description>This document is a purchase order for Northwind    Traders. </description>

The datatype element is used to specify the data type of an element or an attribute. The datatype element uses predefined data types. The current data types are listed in the following table.

Current Data Types

Data Type	Description
bin.base64	A MIME-style base64-encoded binary large object (BLOB).
bin.hex	Hexadecimal digits representing octets.
boolean	0 or 1, where 0 = "false" and 1 = "true".
char	A string, one character long.
date	A date in a subset ISO 8601 format, without the time data¡ªfor example, "2000-11-05".
dateTime	A date in a subset ISO 8601 format, with an optional time and no optional zone¡ªfor example, "2000-07-07T18:39:09". Fractional seconds can be as precise as nanoseconds.
dateTime.tz	A date in a subset ISO 8601 format, with an optional time and an optional zone¡ªfor example, "2000-04-07T18:39:09-08:00". Fractional seconds can be as precise as nanoseconds.
fixed.14.4	The same as number, but no more than 14 digits to the left of the decimal point and no more than 4 digits to the right.
float	A real number that has no limit on the number of digits; it can have a leading sign, or fractional digits, or an exponent. Punctuation is in U.S. English. Values range from 1.7976931348623157E+308 through 2.2250738585072014E-308.
int	A number, with optional sign, no fractions, and no exponent.
number	A number that has no limit on digits; it can have a leading sign, fractional digits, or an exponent. Punctuation is in U.S. English. Values have same range as the most significant number, r8¡ªthat is, 1.7976931348623157E+308 through 2.2250738585072014E-308.
time	A time in a subset ISO 8601 format, with no date and no time zone¡ªfor example, "08:15:27".
time.tz	A time in a subset ISO 8601 format, with no date but an optional time zone¡ªfor example, "08:1527-05:00"
i1	An integer represented in one byte¡ªthat is, a number with an optional sign, no fractions, and no exponent¡ªfor example, "1, 127, -128".
i2	An integer represented in one word¡ªthat is, a number with an optional sign, no fractions, and no exponent¡ªfor example, "1, 703, -32768".
i4	An integer represented in four bytes¡ªthat is, a number with an optional sign, no fractions, and no exponent¡ªfor example, "1, 703, -32768, 148343,-1000000000".
r4	A real number, with no limit on digits. Can potentially have a leading sign,fractional digits, and optionally an exponent. Punctuation is in U.S. English. Values range from 3.40282347E+38F through 1.17549435E-38F.
r8	The same as float¡ªthat is, a real number that has no limit on the number of digits. Can have a leading sign, fractional digits, or an exponent. Punctuation is in U.S. English. Values range from 1.7976931348623157E+308 through 2.2250738585072014E-308.
ui1	An unsigned integer¡ªthat is, an unsigned number with no fractions and no exponent¡ªfor example, "1,255".
ui2	An unsigned integer represented in two bytes¡ªthat is, an unsigned number with no fractions and no exponent¡ªfor example, "1,255,65535".
ui4	An unsigned integer represented in four bytes¡ªthat is, an unsigned number¡ªwith no fractions and no exponent¡ªfor example, "1,703,3000000000".
uri	A URI¡ªfor example, "urn:schemas-microsoft-com:Office9".
uuid	Hexadecimal digits representing octets, optionally embedded with hyphens that are ignored¡ªfor example, "333C7BC4-460F-11D0-BC04-0080C7055A83".

The datatype element has one attribute: dt:type. The dt:type attribute can be set to one of the values in this table.

The datatype element can be used as shown here:

<datatype dt:type=="char"/>

Declaring attributes in BizTalk schemas is a two-step process. First, you must define the attribute using the AttributeType element. Second, you associate this attribute with an element using the attribute element. If the AttributeType element is declared as a child element of the Schema element, the AttributeType element will have document-level scope. If the AttributeType element is a child element of an ElementType element, it has local scope to that element. This scenario is similar to the W3C standard.

The AttributeType element can have two child elements: description and datatype. The datatype element can be used interchangeably with the dt:type attribute. For attributes, the Microsoft XML parser can use only the following data types: entity, entities, enumeration, id, idref, idrefs, nmtoken, nmtokens, notation, and string. You can use the dt:values attribute to list the possible values for an enumerated type when dt:type is set to enumeration.

The value of the default attribute is the default value for the attribute. If dt:type is set to enumeration, the value of the default attribute must be one of the values listed in dt:values.

The name attribute specifies the name of the AttributeType element; it will be used to reference the AttributeType element. The required attribute indicates whether the attribute is required.

An example of an AttributeType declaration is shown here:

<AttributeType name="colors"     dt:type="enumeration" dt:values="red green"/> <AttributeType name="pageCount" dt:type="int"/>

The element element is used to declare child elements of an element. Thus, the element element is always a child element of either an ElementType element (which defines elements) or a group element. Just as you could for the element element in the W3C schema, you can define the number of occurrences of an element child element.

With BizTalk schemas, you will also use the minOccurs and maxOccurs attributes. In this case, minOccurs can only be 0 or 1. If minOccurs is 0, the element is optional; if it is 1, the element must occur once. The maxOccurs attribute can only be 1 or an asterisk (*). If maxOccurs is 1, the element can appear at most once; if it is *, the element can appear an unlimited number of times. This is different from the W3C schema, which allows any value to be assigned to minOccurs and maxOccurs.

The BizTalk group element is similar to the group element of the W3C schema, but unlike the group element defined in the W3C standard, the BizTalk group element cannot be a child element of the schema element. This means that you cannot have document scope group elements. A group element can be used only to group elements within an element declaration¡ªfor example, within an ElementType declaration. One of the most useful features of the group element is that it can be used to define a sequence for the child elements of an element.

The group element contains element child elements. The sequence of the child elements can be specified by using the group element's order attribute. If the order attribute is set to one, there can only be one instance of each element in the group. The one value is equivalent to the pipe (|) symbol in a DTD. When the order attribute is set to seq, the elements must appear in the order in which they are declared. Using the seq value is the same as using parentheses and commas in a DTD. The many value indicates that the child elements can appear in any order. The minOccurs and maxOccurs attributes work the same as their counterparts in the element element. We will look at some examples of groups in the section "The ElementType Element" later in this chapter.

Because the Schema element will be included within the body of the BizTalk document, it cannot really be considered a root element. Therefore, instead of calling the Schema element the root element, we will call it the document element¡ªthat is, the highest level element of the BizTalk document. The Schema element indicates the start of a schema definition.

Two namespace attributes should be associated with the Schema element. The first is urn:schemas-microsoft-com:xml-data. This namespace is used by applications such as the Internet Explorer 5 XML parser as a processing instruction to identify the Schema elements defined in the sample DTD at the beginning of this section. This is the default namespace, so you do not have to prefix all the Schema element names with a namespace name. The second namespace attribute is urn:schemas-microsoft-com:datatypes. This namespace is used by applications to include all the data types associated with schemas. The data types listed in the dataTypes entity in the sample DTD are the currently allowable data types for elements.

Our sample DTD allows the following elements to be child elements of the Schema element: AttributeType, ElementType, and description. The description child element can occur once and provides a text description of the business document. Because the AttributeType child element belongs to the Schema element, this element is similar to the attributeGroup element of the W3C schema in that it represents an element with document scope. Unlike the attributeGroup element, however, the AttributeType element allows you to define only a single type of attribute instead of a group of attributes. The ElementType child element is equivalent to the element element in the W3C schema and is used to define elements.

An example of a Schema element is shown here:

<Schema name="NorthwindSchema"     xmlns="urn:schemas-microsoft-com:xml-data"    xmlns:dt="urn:schemas-microsoft-com:datatypes">     </Schema>

The ElementType element is used to define an element type. The ElementType element can have the following child elements: attribute, AttributeType, datatype, description, element, and group. The AttributeType element will create local definitions for the attribute element, the attribute element will be used to define attributes associated with the element, and the element element will be used to define child elements of the element. The datatype element can define an element as being any of the data types listed in the table in the section "The datatype Element."

You can also declare an element as a certain type by using the dt:type attribute as one of the attributes of the ElementType element. In addition to this attribute, the ElementType element also has the model, order, content, and name attributes. The model attribute is used to indicate whether an element can contain content defined only in the content model or can contain content not specified in the content model. A content model is a pattern that you set up to declare what child element types are allowed inside an element and the order of those child elements. If the model attribute is set to open, the default value, the element can contain content that is not specified in the content model. In this case, this attribute is similar to the any type in the W3C standard. If the model attribute is set to closed, the element can contain only content that is defined in the content model.

The order attribute functions the same as its counterpart in the group element. The content attribute can be empty when there is no content, textOnly when the content is only text, eltOnly when the content is only elements, and mixed when the content is a mixture of elements and text. The name attribute defines the name of the element.

NOTE

---

If the model attribute is open and the content attribute is textOnly, the content can be both text and unnamed elements.

An example of the ElementType element is shown here:

<Schema name="NorthwindSchema"     xmlns="urn:schemas-microsoft-com:xml-data"    xmlns:dt="urn:schemas-microsoft-com:datatypes">    <AttributeType name="colors"        dt:type="enumeration" dt:values="red green"/>    <ElementType name="3Dimage" content="eltOnly" model="closed">       <attribute type ="colors"/>       <AttributeType name="width" dt:type="int"/>       <attribute type = "width"/>       <group order="seq">          <element type="x"/>          <element type="y"/>          <element type="z"/>       </group>    </ElementType>     </Schema>

This schema declares a document scope AttributeType element named colors that is defined as an attribute in the 3Dimage element by using the attribute element. A local declaration of an AttributeType element named width is also defined as an attribute in the 3Dimage element by using the attribute element. This pairing of a local AttributeType element followed by an attribute element that uses the AttributeType element as an attribute is the most common way to use these elements. The schema also uses a group element to sequentially group elements.

The following example demonstrates a valid use of this schema:

<3Dimage color="blue" width="5">    <x>1</x>    <y>3</y>    <z>6</z> </3Dimage>

If you change the value of the order attribute in the group element to one in the schema, this example would be invalid; but the following example is valid with the changed schema:

<3Dimage color="blue" width="5">    <x>1</x> </3Dimage>

You can also declare an ElementType element as a data type. The following declaration creates an integer element named quantity:

<ElementType name= "quantity" dt:type="int"/>

This element could also be declared as shown here:

<ElementType name= "quantity" >    <datatype dt:type="int"/> </ElementType>

In Chapter 7, we created a schema based on the W3C standard for the Northwind Traders database. This schema rewritten as a BizTalk schema is shown here.

<Schema name="NorthwindSchema"     xmlns="urn:schemas-microsoft-com:xml-data"   xmlns:dt="urn:schemas-microsoft-com:datatypes">  <ElementType name="Categories"        xmlns:Categories="urn:northwindtraders.com.Categories"        content="eltOnly"  model="closed">       <group order="seq">          <element type="Categories.CategoryID" minOccurs="1"              maxOccurs="1" />          <element type="Categories.CategoryName" minOccurs="1"              maxOccurs="1" />          <element type="Categories.Description" minOccurs="0"              maxOccurs="1" />          <element type="Categories.Picture" minOccurs="0"              maxOccurs="1"/>       </group>    </ElementType>    <ElementType name="Categories.CategoryID"        xmlns:Categories="urn:northwindtraders.com.Categories"        dt:type="integer">       <description>          Number automatically assigned to a new category       </description>    </ElementType>    <ElementType name="Categories.CategoryName"         xmlns:Categories="urn:northwindtraders.com.Categories"        dt:type = "string">       <description>Name of food category</description>    </ElementType>    <ElementType name="Categories.Description"        xmlns:Categories="urn:northwindtraders.com.Categories"       dt:type="string"/>    <ElementType name="Categories.Picture"        xmlns:Categories="urn:northwindtraders.com.Categories"       dt:type = "bin.base64">       <description>          Picture representing the food category        </description>    </ElementType>    <ElementType name="Customers"        xmlns:Customers="urn:northwindtraders.com.Customers"        content="eltOnly" model="closed">       <group order="seq">          <element type="Customers.CustomerID" minOccurs="1"              maxOccurs="1"/>          <element type="Customers.CompanyName" minOccurs="1"              maxOccurs="1"/>          <element type="Customers.ContactName" minOccurs="1"              maxOccurs="1"/>          <element type="Customers.ContactTitle" minOccurs="0"              maxOccurs="1"/>          <element type="Customers.Address" minOccurs="1"              maxOccurs="1"/>          <element type="Customers.City" minOccurs="1"              maxOccurs="1"/>          <element type="Customers.Region" minOccurs ="1"              maxOccurs="1"/>          <element type="Customers.PostalCode" minOccurs="1"              maxOccurs="1"/>          <element type="Customers.Country" minOccurs="1"              maxOccurs="1"/>          <element type="Customers.Phone" minOccurs="1"              maxOccurs="1"/>          <element type="Customers.Fax" minOccurs="0"              maxOccurs="1"/>       </group>    </ElementType>    <ElementType name="Customers.CustomerID"        xmlns:Customers="urn:northwindtraders.com.Customers"        dt:type="CustomerIDField">       <description>          Unique five-character code based on customer name        </description>    </ElementType>    <ElementType name="Customers.CompanyName"        xmlns:Customers="urn:northwindtraders.com.Customers"        dt:type="string"/>    <ElementType name="Customers.ContactName"        xmlns:Customers="urn:northwindtraders.com.Customers"        dt:type="string"/>    <ElementType name="Customers.ContactTitle"        xmlns:Customers="urn:northwindtraders.com.Customers"        dt:type="string"/>    <ElementType name="Customers.Address"        xmlns:Customers="urn:northwindtraders.com.Customers"        dt:type="string">       <description>Street or post-office box</description>    </ElementType>    <ElementType name="Customers.City"        xmlns:Customers="urn:northwindtraders.com.Customers"        dt:type="string"/>    <ElementType name="Customers.Region"        xmlns:Customers="urn:northwindtraders.com.Customers"       dt:type="string">       <description>State or province</description>    </ElementType>    <ElementType name="Customers.PostalCode"        xmlns:Customers="urn:northwindtraders.com.Customers"        dt:type="string"/>    <ElementType name="Customers.Country"        xmlns:Customers="urn:northwindtraders.com.Customers"        dt:type="string"/>    <ElementType name="Customers.Phone"        xmlns:Customers="urn:northwindtraders.com.Customers"        dt:type="string">       <description>          Phone number includes country code or area code       </description>    </ElementType>    <ElementType name = "Customers.Fax"        xmlns:Customers="urn:northwindtraders.com.Customers"        dt:type="string">       <description>          Fax number includes country code or area code       </description>    </ElementType> </Schema>

 As you can see, a few changes have been made between the W3C version and the BizTalk version of this schema. The annotation elements have been replaced by description elements. There is no equivalent to the W3C datatype element, nor can you set a continuous range of values (such as 1 through 100). Also, the data type content has been replaced with the content attribute.

One of the fundamental concepts of BizTalk is the creation of a central repository of schemas that can be shared by any organization. The BizTalk Web site is located at http://www.BizTalk.org. There you can search existing published schemas, publish your own schemas, and use schemas in the repository to validate documents. Published schemas can be accessed by referring to them in your XML documents

So far, we have looked at three different ways of defining XML documents. We now need to ask ourselves which is the best one for our current systems. The W3C schema is not currently being implemented in many applications because it is not a finalized standard. At the time of this printing, the W3C standard should be in candidate status, however, and it is likely that applications will begin to use it. The W3C standard is the future, and once applications such as the Microsoft, SUN, and IBM XML parsers begin using it, others will follow.

Until the W3C schema standard is implemented, the BizTalk schema can be used. When the W3C schema standard is complete, none of the XML documents based on a BizTalk schema will need to be changed. The only thing that will have to change is the schema located in the repository. It is likely that an application will be available that will automatically convert a BizTalk schema to the W3C schema, or you could write one yourself. While we are waiting for the final W3C standard to be completed, the BizTalk schema is the ideal interim candidate. The BizTalk schema has many advantages, including ease of use, simplicity, and a set of data types.

There is little question that movement of data across boundaries is one of the greatest challenges facing large and small corporations today. As we have mentioned, XML is the best available solution for moving data across boundaries, and we can use schemas to validate XML documents. In fact, you can spend the next year writing applications that do not use schemas, or that don't even work with XML, and then upgrade all of your applications when the W3C schema specification is released. However, by rewriting your applications, you will likely incur a large expense and waste a great deal of development time over the next one or two years. So a better choice is to write your applications using BizTalk schemas now and then upgrade only your schema when the new specification is complete. Using the BizTalk schema now will result in applications that integrate with the next generation of applications and require little expense to upgrade.

Even though BizTalk does offer many advantages over DTDs, DTDs do still have a place in the current development of XML. On the minus side, however, DTDs are much more complicated than schemas, especially when entities are used. They are also not written in well-formed, valid XML. On the plus side, DTDs have been in use for some time and are widely implemented across virtually every platform.

NOTE

---

The large software corporations are currently divided on how to implement XML. As you know, Microsoft, working with other organizations such as SAP and CommerceOne, has developed BizTalk so that corporations can begin to implement XML solutions using schemas now. In response to BizTalk, IBM, SUN, and other organizations have formed a group called OASIS and created their own schema repository, which can be found at http://www.xml.org. They are developing ebXML, which is similar to BizTalk but works only with the XML 1.0 standard¡ªthat is, only with DTDs.

As we have mentioned, the entire purpose of schemas and DTDs is to validate documents. The easiest means of accomplishing this is to have parsers, such as the Microsoft XML parser, that can validate XML documents using schemas. If a cross-platform parser for BizTalk schemas were available, the schemas could be used to validate any XML document on any platform. Unfortunately, only the Microsoft XML parser supports BizTalk schemas. If the information is passing across a Microsoft system boundary into another Microsoft system, support is not an issue. When information is moving over a boundary and across platforms, however, you need to find a way to validate XML documents. You can use the following three options.

The first option is to extend the Java or C++ parsers provided by SUN and IBM so that they use schemas instead of DTDs to validate documents. This means that all the non-Microsoft systems must have this custom-built parser installed on their servers. This may be an acceptable solution when you are working with a corporate partner or building internal solutions.

The second option is to pass the information across a boundary to a Microsoft BizTalk server, which will then pass the information over another system boundary to the non-Microsoft systems. The BizTalk server will perform the validations and then send the appropriate information to the correct server and method. When Microsoft releases its new BizTalk server, this solution will probably be the best. This too is an acceptable solution when you are working with a corporate partner or building internal solutions.

The third option is to use DTDs. Ideally, you want to be able to build a solution that is platform independent, meaning that you don't need to know whether the person on the receiving end has a BizTalk server. In many circumstances, you will be dealing with multiple organizations and will have no idea what platform they are using. For example, if you are publishing real estate information to all the real estate brokers in a certain area, you will have no way of knowing what system each broker is using. In this case, you need a platform-independent way of moving information to the recipients. As mentioned, BizTalk won't currently work in this situation. Until schemas become a widely accepted standard across all platforms, DTDs can still be used to validate XML documents. When you are working with UNIX and mainframes, DTDs will probably be the best solution until the W3C standard is released and used by all organizations.

When all platforms have applications that work with schemas, schemas will be the better choice. This shift will probably take place within the next year or two. When possible, you should try to use BizTalk schemas when building new applications. When cross-platform issues prevent the usage of schemas, DTDs will have to be used for now.

Once you have made the decision to use XML, you will need to decide how to build your schemas. It is likely that you will be using XML to upgrade your current systems and to build new ones. The first step in using XML for these systems is identifying the type of information that is being moved throughout the corporation and what information is being moved across system boundaries.

The best way to begin identifying information is by looking at the forms that are currently being used or that will be used to input and review information. These forms contain fields that represent all the information required to complete a task. If you use Unified modeling language (UML) use cases (a text description of a task that uses a predefined format) to design a system, each use case will represent a task and define the information required to complete that task in business rules. As you look through the forms that exist in the corporation, try to identify general information structures. For example, you might find that a core set of information is used to define a customer throughout the corporation. Based on this core set of information, a base customer schema is created to define customer information. If other applications require additional information, namespaces can be used to include the base customer schema in another schema with the additional information.

Most corporations have generated large quantities of documentation about workflow and batch process. This documentation can be used to identify the information that is being moved through the corporation. Be aware of the fact that processes are often extended, producing two or more similar processes. These extensions are usually the result of new requirements or new systems that perform functions similar to those of existing systems. As time goes on and more and more extensions develop, the batch processes become huge and extremely redundant. Try to find the common elements in the batch processes and build schemas that bring together common elements and simplify the business event model.

The business event model represents the flow of events, from the beginning to the end, for a business process. It is a tool that helps you define your system and the information flowing through the system, but remember that it is only a tool. Modeling the system should be done only to the extent that it helps you understand the system, the information in the system, and the flow of information through the system. Developing a business event model that does this should not take a great deal of time. If you find that a large quantity of resources is being dumped into modeling and nothing is being built, the model has taken on a life of its own and has gone beyond its usefulness. It's often best to start by modeling small parts of your system.

NOTE

---

You can get more information about building your schema by reading the chapter "So, What's a Schema?" of the online book ABC's of Schema, by Dan Rogers. You can find this book at http://www.biztalk.org/News/newsRead.asp?NewsID=204705.

BizTalk Framework 2.0 provides a means to move information contained in a SOAP document across boundaries. BizTalk document elements are wrapped in BizTags. Each BizTalk document must use the appropriate BizTags in the SOAP Header section and contain the structured business transaction information in the SOAP Body section. The BizTalk message can be defined and validated using schemas. You can use the BizTalk message to create a loosely coupled message that can be sent across any boundary.

Currently, only the Microsoft XML parser can properly validate BizTalk schemas. It is likely that when the W3C schema is complete, all the major software companies will add the capability to validate XML documents with schemas. When this happens, the BizTalk format will provide the capability to move information across boundaries to and from any software platform.

Up to this point, we have discussed the basic structure of XML, DTDs and schemas that are used to define XML documents. We have also examined SOAP 1.1 and the BizTalk Framework 2.0. In the rest of the book, we will see how to actually write applications using the knowledge we have gained in the first half of the book.