BizTalk

Microsoft Corporation started BizTalk as a way to help break down the significant obstacles faced by companies of integrating applications, both within their organizations and among their trading partners . Companies' internal systems, such as enterprise resource planning, accounting, and marketing support (for example, sales tracking) are often developed independently of each other. As a result, a company's information technology staff often finds itself strapped trying to get these systems to work together.

The problem is compounded when trying to get one company's systems to interact with those of suppliers, customers, financial services, and government services. The same integration problems faced internally are now magnified when transacting business across organizational boundaries.

As this book discusses at length elsewhere, XML helps overcome some of the challenges. Because of its status as a respected W3C technical specification, XML provides a way to devise a common vocabulary that can help companies define common messages and bridge this gap. Microsoft offers BizTalk to provide a common business message framework, as well as a community to encourage solutions that offer greater interoperability.[26]

BizTalk includes a framework specification and a repository of schemas called Biztalk.org complying with this specification. The Biztalk.org site also functions as a self-help community for BizTalk users. Microsoft offers a BizTalk server that supports the framework specification. In December 2000, Microsoft announced its release for licensing and general availability. According to the announcement, some 50 companies are already using the BizTalk server in some production capacity.[27]

The following sections discuss the BizTalk framework specification and the related Biztalk.org repository. It should be noted that as of mid 2001 the Microsoft BizTalk server system does not have a native capability to interact with ebXML-compatible systems. However, since it does support SOAP-based messaging exchanges, there appear to be no large technical barriers for the BizTalk server to physically transfer ebXML-compatible content as simple payloads.

BizTalk Framework

The BizTalk Framework, now in version 2.0, provides specifications for the exchange of XML documents and messages. The specifications give detailed instructions for constructing these messages and for their transfer using standard Internet protocols. They identify four sets of requirements that any solution needs to address:

• A language with the capability to specify and exchange structured or unstructured information across organizations and applications

• Support for transformation rules to allow for the conversion of formats across organizational and application boundaries

• Communication protocols at the application level to enable message transfers across computing platforms, as well as organizations and applications

• Ability to secure messages for integrity, privacy, and non- repudiation

The document notes that XML addresses some of these concerns, but with the proliferation of business vocabularies defined in XML, the need for a common framework to provide interoperability also increases . And while systems and software for translating among these different vocabularies, called middleware, are coming onto the market, none of them meet all of the requirements for interoperability.

BizTalk is based largely on XML, with support for both Microsoft's own XML Data Reduced (XDR) and the W3C Schema syntax, but also incorporates other Internet standards such as Hypertext Transfer Protocol (HTTP), Multipurpose Internet Mail Extensions (MIME), and other XML vocabularies such as the Simple Object Access Protocol (SOAP). It doesn't deal with issues such as trading partner agreements or business process specifications. BizTalk 2.0 builds on the first version by adding more features compliant with SOAP, as well as more transport-related features, MIME, and the emerging XML-Schema specifications from the W3C.[28]

Logical Layering

The BizTalk framework addresses three basic layers in the interactions among companies:

• Transport ” the delivery mechanism over the Internet, using protocols such as HTTP (web) or SMTP (email)

• BFC Server ” functions provided by a server compliant with the BizTalk framework

• Application ” responsible for generating and processing business documents

Most of the BizTalk framework specifications focus on the BizTalk Framework Compliant (BFC) Server, although they also define the bindings, connections, and interfaces to the transport protocols and business applications.[29]

BizTalk Document Header

The message structure for BizTalk documents uses the Simple Object Access Protocol (SOAP) that includes an outer envelope layer, as well as header and body sections. The header describes the message's routing, provides identification, indicates the services required, and offers a listing of the message contents. The SOAP header in BizTalk requires the mustUnderstand attribute with a value of 1, which means that the recipient of the message must process the header entries.

For these functions, the header has a series of elements:

• endpoints

• properties

• services

• manifest

• process

The endpoints element, mandatory in a BizTalk message, identifies the message and destination, using sub-elements labeled to and from . BizTalk allows either use of technical locations, such as web addresses, or business-defined identifiers, such as D-U-N-S numbers or tax IDs. If business identifiers are used, the transport protocols in the outer layers need to provide the delivery location in order to have the message delivered. Also, the syntax of the delivery location may depend on the software running respective servers.[30]

The properties element, also mandatory, provides identification for the message. The identifiers include a machine-generated unique string using a protocol such as the Universal Unique Identifier (UUID), as defined by The Open Group .[31] The identifiers also include sent-at and expires -at elements defining the lifetime of the document for business action.

The properties element has a sub-element giving the topic or general subject matter of the message. BizTalk recommends using a consistent way to name the topic, such as web address or URI, so that the receiving system can accurately interpret the contents.[32]

The services element refers to delivery services, and provides directions for reliable delivery of the BizTalk message, as well as an indicator of the intended recipient. A deliveryReceiptRequest sub-element indicates the desire for a delivery acknowledgment from the receiver. A commitmentReceiptRequest indicates the need for a business acknowledgment (as opposed to technical delivery) of the message's substance. Both the delivery and commitment sub-elements give addresses to which the recipient should return these acknowledgments, as well as deadlines for their receipt.[33]

The manifest element gives a catalog of the message contents. This catalog not only lets the receiver know the contents of the message body, but indicates the presence of attachments or references to external documents that serve the same function as attachments. BizTalk allows for MIME format when messages need to carry both XML and non “XML data. The manifest indicates the presence of an attachment, and thus the presence of a compound document using the MIME format.The recipient can use the manifest to double-check that all attachments arrived intact.

The manifest element consists of one or more reference sub-elements that identify either an attached document or an external reference that acts as an attachment. For example, an external reference may consist of a web address pointing to a large graphics file that the recipient can download separately if needed.[34]

The process element describes the business process context of the BizTalk document. A type sub-element identifies a business process already agreed upon by the trading partners for understanding the substance of the message. For example, an invoice message may be part of a larger payments process that the message could reference in this part of the header.To further identify the process, the element has an instance sub-element to identify a specific document that describes the process and that the recipient can reference. The process element has an additional detail sub-element that provides for further references or a location to report exceptions.[35]

BizTalk Document Body

The BizTalk body uses the SOAP body structure. The body of a BizTalk document references an XML namespace that defines the application governing the business content. If the body of the message contains multiple documents ”for example, an invoice and separate payment instructions ”BizTalk uses a feature of SOAP that specifies whether subsequent parts of the body are considered sub-elements or separate elements.[36]

BizTalk doesn't specify the business content of the message body beyond data types derived from the XML Schema specification. The document identifies three data types from XML Schema:

• timeInstant ” a date/time stamp meeting the format requirements of ISO standard 8601 (representations of dates and times)

• uriReference ” an Internet resource, such as a web address, which can be an absolute address (complete syntax), or relative address pointing to another location on a referenced site

• complexType ” an element with more than one kind of content related to each other; for example, a text string and decimal number combined as a street address

BizTalk also specifies the xsi : type attribute from the XML Schema document for elements to identify their specific data types.[37]

Reliable Delivery of BizTalk Messages

BizTalk provides for two kinds of services to help ensure that trading partners receive and act on the messages exchanged, as well as prevent duplication of messages that can cause duplicated actions. The specifications define two types of receipts: delivery and commitment receipts (discussed earlier).

BizTalk recommends a set of actions for message senders and receivers, called endpoints in the specifications. Senders should maintain copies of messages in durable storage for any needed recovery in case of failure. Senders should also request delivery receipts and correlate those receipts with the original message identifiers. Retries should continue until a receipt for the message is returned, the deadline in the delivery receipt expires, or the maximum retry count is exceeded.

Receivers of BizTalk messages should also process and return delivery receipts, as well as develop procedures ensuring that the message is delivered and processed only once. The specifications recommend maintaining durable storage of all accepted BizTalk documents until the expiration date in the header. Receivers of messages may be able to log only the identities of the documents rather than the documents themselves , since they are required to use a unique identifier.[38]

Securing BizTalk Messages

BizTalk provides for three kinds of security for its messages: enveloping (encryption), signing, or a combination of enveloping and signing. Since the combination of message header, body, and attachments may require different levels of security within the same message (for example, encrypted attachment only), the specifications provide detailed instructions and references to the original S/MIME documentation.[39]

BizTalk.Org Repository

Microsoft offers BizTalk users a registry for the schemas (www.biztalk.org) that users develop according to the BizTalk specifications. BizTalk.org stores the schemas in a web-based repository that makes the schemas available to the public at large. Companies or organizations developing schemas can also register them privately so only the trading partners can access them.

The BizTalk.org repository allows registered users to access the repository of schemas. All of the public schemas are categorized by industry category with the North American Industry Classification System (NAICS).[40] The site lets visitors browse, view, or download the schemas, as well as sample code and documentation about each schema.

Early in its development, BizTalk required its schemas to use a special flavor of XML called XML Data-Reduced (XDR), a subset of XML-Data, which was a predecessor of XML-Schema.[41] As a result, all of the 454 schemas registered with BizTalk.org as of mid-February 2001 use the XDR format. On 31 January 2001, Microsoft announced that BizTalk.org started accepting schemas in the XML Schema format.[42]

Companies or organizations can register their schemas with BizTalk.org without physically storing them in the repository. The registration captures the following information about each schema:

• Object name, the name displayed for the schema

• Summary, a brief description

• File name when stored with BizTalk.org

• Keywords to help visitors search the schemas

• Schema location in BizTalk.org or on another server

• Schema sample location, a sample document validated against the schema

• Documentation, giving contact details, error handling instructions, and any other special conditions[43]

BizTalk.org also connects to BizTalk newsgroups to help build a community of users, as well as help and background files.