This document describes the version 0.8 BizTalk Framework specifications for XML tags that are used to transmit information between businesses or between applications within a business. The intended audience is technical personnel that are responsible for design and implementation of commercial or non-commercial interoperability solutions using XML. In this document, the elements and structures and codes that are required for a BizTalk Framework schemas are defined.

"We use XML to encode our data, how about you?"

It’s been said that to say that you use XML is like saying you use ASCII. The format is so flexible that no two uncoordinated efforts wind up being compatible. The problems in describing information using XML range from deciding what to describe all the way to what to name each field. Once you’re beyond those non-trivial issues, you need to then tag your data so that another party or application can recognize what it is that you’ve sent them.

This marking of data so that it can be recognized, routed, and efficiently handled is the purpose of this document.

The BizTalk Framework defines a consistent way to use XML, making it easy to determine the basic type of every message independently of the particular information it contains. This document describes the required BizTalk Framework document and optional tags that define BizTalk Framework messages. These special codes, structures and tags are used to annotate information that is passed between computer programs in the exchange of well-structured information.

The tag formats defined in this specification set the ground-level encoding rules that allow a broad number of independent sources to each mark-up their own XML documents, messages and data in a consistent way. The benefits of driving this de-facto agreement on simple XML tagging conventions include enabling applications that are built independently and without each other in mind specifically to at some point be able to interchange information as called for by the needs of business.

So why do we want to do this? The BizTalk Framework allows software developers to write applications that can more easily process documents than they can today. The mere ability to examine any document and determine – without qualification – the type and version of that document, is significant. Further benefits include the ability to identify the source of the document, as well as information about the internal structure of the data contained. Finally, each document that follows these specifications contains information about the intended destination, its source and the route that the document followed.

This version 0.8 specification defines enough detail to make a significant contribution, to allow the broad community of XML-interested developers and designers to design implementations using these specifications, and to gather feedback that will be included in the version 1.0 specification.

The BizTalk Framework version 0.8 specification covers the following features:

This specification is a preview release of the BizTalk Framework specification. By releasing this information at this stage, Microsoft hopes to stimulate feedback that will be used to define the 1.0 version of the specifications as well as the full release version of the BizTalk Framework.

The tags defined in this preview specification support programmatic determination of document identity and routing information of XML documents by defining mandatory XML tag and usage specifications. Parties that use these tags will be able to interchange documents in a more fluid manner than and with less effort than those that choose to implement information interchange without licensing the BizTalk Framework or by standardizing on integration technologies based on programming languages or distributed computing technolgies.

Issues and capabilities not covered in this preview include sequencing, security, and fully defined conversational tag support. The v0.8 routing tags and codes are flexible enough to accommodate a broad degree of sequencing requirements, and transport selection. Privacy features that are part of the 1.0 version of the BizTalk Framework are not covered. At this time, secure transport technologies that are generally available (e.g. SMIME, SSL, etc.) can be used to achieve on-the-wire encryption, signatures and error detection.

The XML tags defined in the BizTalk Framework are a closed model. However, because XML is extensible, capabilities not defined in the version 0.8 Framework can be added in future versions without disrupting the interpretation of 0.8 tags.

The version 0.8 BizTalk Framework specification defines a way to use XML to exchange documents and messages that need to be transmitted from one computer program to another, either directly (via inter-process communication software such as http, SMTP, message queue, etc.), or indirectly (via file exchange or batch job). The BizTalk Framework at this time provides support for document structure, document identification and message flow information.

Document identification is important in two regards. First, by defining consistent tags and structures, the task of creating automated document processing solutions becomes simpler. Businesses that use the BizTalk Framework will not need to negotiate or design point-to-point solutions for information interchange. BizTalk Framework rules allow businesses to adopt a consistent approach to document encoding (e.g. structure) and to publish their document definitions, as appropriate, in a publicly available repository, with or without security. Since one of the first tasks a program faces when processing information is determining what it is that is being processed, the document identity tags eliminate the need to negotiate the location of identity information.

Throughout this and other BizTalk Framework documentation, you’ll find the term document used to describe information encoded in XML. This term has been chosen partly due to the conventions that currently permeate XML technical specifications. It is also the appropriate term, in most cases, as the information that is passed between computer systems or applications often replaces paper documents that once filled the same role. These documents are used to convey information between business processes that are related to or depend upon each other. The term document, used in this way, is also less ambiguous than the term data, since that term refers to a vast and unspecific subject area.

The term message is a special case of the term document. Where a document can be used to express any sort of information, a message flow involves a directed request being sent from one computer program to another. A directed request is sent by one program to another with the expectation that the second program will then do some useful action. In this regard, the concept of a message can be distinguished from data that is simply recorded and expressed as an XML document.

Messages are the basis for the most significant contributions of the BizTalk Framework. A message flow between two or more applications is a means to integrate applications at the business process level by defining a loosely-coupled, request-based communication process. Since many business processes involve one party performing a service at the request of another party, the mapping of messages to requests is natural. Approaches making tighter integration demands, such as those based on special programming languages or shared distributed computing "platforms" are highly appropriate to tightly-connected applications on single machines or in controlled environments, but they don’t adequately support distributed, loosely-coupled, extensible business process integration. An XML-based messaging system, with open, extensible wire formats captures the essentials of a business communication while allowing flexible implementations.

The eventual benefit of using the BizTalk Framework as your core process integration approach will be a dramatic increase in process flexibility as well as significant cost reductions in information technology expenditures. The flexibility is directly attributed to the degree that you take advantage of messages, message exchange, and loosely-coupled application integration. Messages that describe what you would like to accomplish, and avoid technical dependencies related to how it needs to be processed, make it possible to do things such as upgrading or replacing applications, add intermediating or consolidating stages, or forge new business relationships with your customers, suppliers and partner companies.

The general format of a BizTalk Framework document is shown below. This section covers the description of the elements that make up a tagged document. For companies that use the BizTalk Framework to define documents that adhere to these rules, a branding opportunity is provided. Documents that are described by BizTalk Framework Schemas, pass validation tests and are published on BizTalk.org can be called BizTalk Framework Documents. The following mandatory elements are the basis for document validation:

BizTalk Framework documents and messages must use XML-Data to define and encode information. XML-Data is currently a note submission to the W3C, and serves as an interim schema definition standard until the W3C adopts a formal XML schema standard.

A BizTalk Framework document must begin and end with the following XML tags:

<BizTalk xmlns="urn:schemas-biztalk-org:BizTalk/biztalk-0.8.xml">

</BizTalk>

This is known as the Root Tag. These outer tags define a document as being a BizTalk Framework version 0.8 document, using elements from the BizTalk namespace. (This namespace reference makes it unambiguous that the message envelope is defined by the BizTalk Framework specifications, and permits a receiver to validate this.)

For a document to be labeled a BizTalk compliant document, the outer tags must begin and end as shown. Without these tags, the application that is processing a document to extract its data will not be able to locate further information described by BizTalk.

Within the root element, the following elements must appear:

<Body xmlns="urn:your-namespace-here">

</Body>

This is known as the Body Element. This appears within the BizTalk element with no intervening levels of hierarchy. These tags provide a standard way to determine the type of document, the version of the schema used for that document, and a namespace reference to the XML-Data schema description of the document contained within the body block.

The overview general form that describes the mandatory blocks and their relationships is then:

<BizTalk xmlns="urn:schemas-biztalk-org:BizTalk/biztalk-0.8.xml">
<Body xmlns="urn:your-namespace-here">

</Body>
</BizTalk>

In all cases, the contents of the actual document being transmitted will be placed between the begin and end tags for the body block and the first element in the body block will appear without attributes. This first element designates the document type. The MsgType designation shown here is a placeholder for the actual document type name.

Biztalk Framework messages are a refinement of the Biztalk Framework document specifications.

Routing tags consist of three types of tags in BizTalk Framework version 0.8. Structurally, these tags are optional, but their use is strictly defined. If any of the tags are used, all of them must appear. Routing tags are defined to support message delivery using rules based message delivery agents, like the Microsoft BizTalk Server, or other BizTalk-compatible servers. The way that routing tags are assigned values depends on the nature of the applications or business process being integrated. Varying degrees of abstraction appear correct when you examine a single situation. The solution that seems correct for one specific context, however, doesn’t seem to be best in other situations.

Routing messages and documents between applications calls for at least three distinct levels of routing information. These levels can be described as "location", "process" and "instance". At the simplest form, integration via the World Wide Web over HTTP might seem to only call for a single destination – a URL. However, the URL actually represents a location – and gets resolved to a single place somewhere on the planet – that place being a computer.

Two types of routing tags are defined in the BizTalk Framework. These are the "To" and "From" information that is required to support point-to-point message exchanges. These to/from tags take the general form described below:

The element named Route is used to delineate the start of the routing information. This is known as the routing element. In this release, a single routing structure is defined. The contents of the attributes shown (locationID, locationType, process, path and handle) are not specified and the information shown here is for purely sample purposes. The mandatory elements in a routing block are the element and attribute definitions as shown.

Positionally, the routing block must occur between the BizTalk Framework element and the body element. The final form of a BizTalk Framework message structure for version 0.8 is thus:

A description of the routing elements and attributes themselves isn’t sufficient to explain how these tags are used to integrate applications. There are a few design goals that must be understood in order to fully comprehend what capabilities the routing tags allow. A key goal of the BizTalk Framework is to define a way to help programmers stop writing so much code that addresses the low level technical issues associated with integration and allow them to focus instead on higher level, business process issues. To get an understanding of which specific technical issues can be abstracted, let’s examine a tightly coupled integration solution.

In this example, we’ll use COM as our starting point. Let’s assume that we have two applications that are integrated using COM. Whenever one application needs to invoke the services of the other, it simply calls the appropriate method on the other application. During this call, the calling application is placed in a wait state until the service request has been processed. When the call returns, any information returned by the second application is available to process.

From a routing and delivery perspective, this example covers several decisions that were embedded in the programs that were cooperating. The first of these hard coded decisions was the selection of transport. Choosing COM cemented the programs together on a single, mutually supported technology that accomplished the inter-program communication tasks.

The next decision that is reflected in the example program is that the location information specific to the called program’s identity was known ahead of time. While not explicitly reflected in the source code, the location decisions are found in the registry. Without knowing the location in this manner, a run-time call will not operate properly. The registry offers a degree of abstraction, but a very small degree since the CLSID of the called program must be resolved, and the called program must be capable of accepting the incoming COM call.

Contrast this with a BizTalk Framework example. Using a BizTalk routing block attached to a BizTalk Framework document, a calling application fills in the information that is needed to make a delivery service send a message on its way. The calling application could look this information up in a database at run-time – an approach that offers the administrator the opportunity to redirect any request.

The routing elements in version 0.8 allows an application to specify the name of a place – without knowing where the place is or how the request will be eventually be serviced (delivery wise). There are no limitations defined here, however, and the assumption is that the program will employ whatever delivery agent is appropriate.

So how will these routing tags help then? The purpose of the routing tags is to allow a program to create a response to a message it receives. Since the BizTalk Framework routing elements decouples delivery from the application, the routing tags provide the necessary information infrastructure for a delivery mechanism to provide a routable "address" that the delivery mechanism will understand. Since the assumption is that a message will arrive with a functioning routing block, a program that receives a BizTalk Framework message can create and route a response back to the sending application by populating a "To" element with the information contained in the "from" block of an earlier message, and then filling in the "From" block with information that specifies enough details to allow the delivery agents along the way to add information that will allow another application to create a response to this second message by turning around the routing information.

At first glance, point-to-point information would seem to map well to the commonplace URL. However, since URL’s represent location alone, they aren’t entirely sufficient to provide a rich enough routing block. The routing block as shown would support a URL in any of the fields, however, and an appropriately configured BizTalk Framework compatible routing server would be capable of handling a URL address. The remainder of the attributes shown in the routing block can be used to hold information that specify information about other elements that make up a delivery address.

In viewing this information model for a message, one should take care to realize that the model describes the XML that will be used by a service or program that is responsible for processing this information. As such, the information needs to provide sufficient richness to allow an instance of an application or interaction to be identified. A primary goal of the BizTalk Framework routing blocks today is to set the stage for rich interactions that are more complex than simple request/response. To do this, extra attributes are defined that allow four levels of abstraction.

This section defines the purposes of each of the attributes in the routing element. Once a routing element is defined as specified, the document is eligible to be considered a message that conforms to the BizTalk Framework specification for messaging. All of the attributes in each of the routing elements (From/To) are required.

LocationID: This is the abstract information that pertains to a place. This information should be compatible with whatever delivery service or agent is used to manage your flows that use BizTalk messaging.

LocationType: This is a secondary qualifier on LocationID. Some delivery agents provide support for several types. This attribute disambiguates the meaning of the LocationID element.

Process: This tag is for conveying the name of the business or technical process that needs to be invoked or notified when a message is delivered. There are no restrictions on content.

Path: This attribute is provided as a place for a delivery agent to annotate a message as it passes through each delivery agent. The aim is to allow the route that a message travels to be traced, and then reproduced so that a response can be returned to the original sender.

Handle: This attribute represents an abstract identifier that is used by the final application. The purpose of this attribute is to manage differences between instances of exchanges. This is used whenever a sequence of messages is exchanged and needs to be related to each other logically at either side of a complex interchange.

This version 0.8 specification addresses the goals set out by defining the structures, elements and attributes required to establish:

Every message type needs to have an identifier – a URI which will uniquely identify what the body or payload of the message is. This appears in the following tag

<Body xmlns="urn:your-namespace-here">

URI's should appear in the form biztalk.org:company_domain/company's_message_name. For example, urn:schemas-biztalk-org:fabriam-com/purchaseorder.

An individual organization owns the namespace under its domain. Simple names that conform to URI naming standards and describe the business function of the document should be selected.

A company called Fabrikam wishes to send a purchase order to a supplier. Fabrikam’s unique company identifier (a Dunn & Bradstreet number for example) is "111111111". It’s supplier’s identifier is "222222222". These identifiers are used by the BizTalk infrastructure for routing and handling of messages. The BizTalk Framework Tags would look something like this: