Visitor

Resources
Tools
Microsoft XML Parser
3rd Party Vendors
White Papers
Specifications
Links
  The BizTalk Philosophy
The Philosophy behind the BizTalk Framework™.
   
 

BizTalk Framework XML Tags Specification

Executive Summary

This document describes version 0.81 of the technical specifications for Microsoft® BizTalk™ Framework Extensible Markup Language (XML) tags. These specifications consist of message tags encoded in XML. They define a common way to use XML to accomplish identification and routing, and they enable complex interaction. The purpose of the version 0.81 specification is to define the identification markup tags and elicit comments and feedback regarding the routing blocks.

The BizTalk Framework is an XML framework for application integration and electronic commerce. It includes a design framework for implementing an XML schema and a set of XML tags used in messages sent between applications. Microsoft Corp., other software companies and industry standards bodies will use the BizTalk Framework to produce XML schemas in a consistent manner.

Messages are the basis for the most significant contributions of the BizTalk Framework. A message flow between two or more applications is a means of integrating 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 appropriate for 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 business communication while allowing flexible implementations.

Microsoft hereby grants to all users of this BizTalk Framework specification, version 0.81 (the "Specification"), a perpetual, nonexclusive, royalty-free, worldwide right and license under any Microsoft copyrights in the Specification to copy, publish and distribute the Specification. Microsoft further agrees to grant to users a royalty-free license under applicable Microsoft intellectual property rights to implement and use the BizTalk Framework XML tags and schema guidelines included in the Specification for the purpose of creating computer programs that adhere to such guidelines — one condition of this license shall be the party's agreement not to assert patent rights against Microsoft and other companies for their implementation of the Specification. Microsoft expressly reserves all other rights it may have in the material and subject matter of this Specification. Microsoft expressly disclaims any and all warranties regarding this Specification including any warranty that this Specification or implementations thereof does not violate the rights of others.

Information in this document is subject to change without notice.

© 1999, Microsoft Corp. All rights reserved.

 

Microsoft and BizTalk Framework are either registered trademarks or trademarks of Microsoft Corp. in the United States and/or other countries.

Contents

Introduction

Document Overview

Problem Statement

Vision Statement

Requirements

Design Goals and Constraints

Features

BizTalk Framework 0.81

Root Tag — Mandatory

Document Body and Identity — Mandatory

Routing Tags — BizTalk Framework Messages

Routing Mechanics

Discussion Points on Routing

Routing Attribute Definitions

Call to Action

Appendix A: Mandatory BizTalk Framework Tags That Uniquely Identify a Message

Appendix B: Sample Implementation

 

Introduction

Document Overview

This document describes the version 0.81 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 responsible for design and implementation of commercial or noncommercial interoperability solutions using XML. In this document, the elements, structures and codes required for BizTalk Framework schemas are defined.

Problem Statement

"We use XML to encode our data. How about you?"

Some say that using XML to encode data is like using 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 to deciding what to name each field. Once users are beyond these important issues, they need to tag their data so another party or application can recognize what has been sent.

The purpose of this document is to describe ways to mark data for recognition, routing and efficient handling.

Vision Statement

The BizTalk Framework defines a consistent way to use XML, making it easy to determine the basic type of every message independent 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. Driving this de facto agreement on simple XML tagging conventions enables applications built independently and without each other in mind specifically to interchange information as called for by the needs of business.

So why would developers 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 and 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.

The remainder of this document defines the requirements, design goals and technical specifications for BizTalk Framework 0.81. Companies that license the BizTalk Framework may submit and publish schemas and document and message samples to the BizTalk.Org Web site (http://www.biztalk.org/).

This version 0.81 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 version 1.0 of the specification.

Requirements

The BizTalk Framework 0.81 specification covers the following features:

    • Document structure. BizTalk Framework 0.81 defines a general structure for encoding data using World Wide Web Consortium (W3C) XML. Version 0.81 structure consists of a small number of mandatory tags that are used to annotate XML documents and, optionally, messages. These tags consist of definitions, codes and structure definitions that provide the framework to support establishing document identity and routing and that establish the ground rules for usage conventions.
    • Document identity. Document identity can be determined via a standard tag set. Identity includes the designation of basic document type, document design version and document design origin information.
    • BizTalk framework usage. A document encoded with the XML tags defined in this specification should be readily recognizable as being encoded using BizTalk Framework 0.81 tag rules. Documents encoded in this manner can be expected to adhere to all of the rules as defined in this specification.
    • Document routing. A document that supports the optional routing tags (the BizTalk Framework XML tag elements) contains information that describes the processing intent of the sender. Via these optional tags, application programmers can design applications that exchange information in request and response pairs, as well as software that can use XML in a consistent form to support ordered exchanges of documents to enable interchange at the business process level of abstraction.

Design Goals and Constraints

This specification is a preview release of the BizTalk Framework specification. By releasing 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 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. Companies, businesses or developers that use these tags will be able to interchange documents in a more fluid manner 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 technologies.

Issues and capabilities not covered in this preview include sequencing, security and fully defined conversational tag support. The routing tags and codes in version 0.81 are flexible enough to accommodate a broad degree of sequencing requirements and transport selection. Privacy features that will be part of BizTalk Framework 1.0 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 BizTalk Framework 0.81 can be added in future versions without disrupting the interpretation of 0.81 tags.

Features

The BizTalk Framework 0.81 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 provides support for document structure, document identification and message flow information.

Document identification is important in two regards. First, if consistent tags and structures are defined, 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. One of the first tasks a program faces when processing information is to determine what is being processed. The document identity tags eliminate the need to negotiate the location of identity information.

Throughout this and other BizTalk Framework documentation, the term "document" is used to describe information encoded in XML. This term has been chosen partly because of the conventions that currently permeate XML technical specifications. It is also the appropriate term, in most cases, because the information 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 dependent upon each other. The term "document," used in this way, is also less ambiguous than "data" because that term refers to a vast and unspecific subject area.

The term "message" refers to a special kind of document. "Document" can be used to describe any sort of information, but a message flow involves a directed request 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 of integrating 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 for 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 business communication while allowing flexible implementations.

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

BizTalk Framework 0.81

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.

Root Tag — Mandatory

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

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

</BizTalk>

This is known as the "root tag." These outer tags define a document as being a BizTalk Framework 0.81 document, using elements from the BizTalk Framework namespace. (This namespace reference makes it clear 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 Framework-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 the BizTalk Framework.

Document Body and Identity — Mandatory

Within the root element, the following elements must appear:

<Body>

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

</MsgType>

</Body>

This is known as the "body element." It appears within the BizTalk Framework 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 as follows:

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

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

Your document here

</MsgType>

</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 place holder for the actual document type name.

Routing Tags — BizTalk Framework Messages

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

Routing tags consist of three types of tags in BizTalk Framework 0.81. 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, such as Microsoft BizTalk Framework Server or other BizTalk Framework-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 a single situation is examined. 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" tags that are required to support point-to-point message exchanges. These To and From tags take the general form described below:

<Route>

<From locationID="111111111" locationType="DUNS"
process="" path="" handle="3"/>
<To locationID="222222222" locationType="DUNS"
process="" path="" handle="23CF15"/>
</Route>

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 purely for 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.81 is as follows:

<BizTalk xmlns=

"urn:schemas-biztalk-org:BizTalk/biztalk-0.81.xml">
<Route>
Routing tags here
</Route>

<Body>

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

Your document here

</MsgType>

</Body>

</BizTalk>

 

Routing Mechanics

A description of the routing elements and attributes themselves isn’t sufficient to explain how these tags are used to integrate applications. An explanation of a few design goals will clarify 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 clarify 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 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 interprogram communication tasks.

The next decision reflected in the sample program is that the location information specific to the called program’s identity was known ahead of time. Although 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, because the CLSID of the called program must be resolved and the called program must be capable of accepting the incoming COM call.

Contrast this scenario with a BizTalk Framework example. Using a BizTalk routing block attached to a BizTalk Framework document, a calling application fills in the information 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.81 allow an application to specify the name of a place without knowing where the place is or how the request will eventually be serviced (in terms of delivery). 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? The purpose of the routing tags is to allow a program to create a response to a message it receives. Because the BizTalk Framework routing elements decouple 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 enable another application to create a response to this second message by turning around the routing information.

Discussion Points on Routing

At first glance, point-to-point information would seem to map well to the commonplace URL. However, since URLs represent location alone, they aren’t 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 about other elements that make up a delivery address.

In viewing this information model for a message, users should realize that the model describes the XML to 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 is to set the stage for rich interactions that are more complex than simple request and response communications. To do this, extra attributes are defined that allow four levels of abstraction.

To understand the need for several degrees of abstraction, let’s look at the commonplace delivery of information that occurs over HTTP. While some might not consider it as information delivery, an HTTP request consists of route information that describes where to send a request and data that describes the request itself. For simple Web pages, which integrate two physical processes (typically someone’s eyes [or reading process] and someone’s publication [or publication process]), the URL seems appropriate. When we examine even URLs though, two degrees of abstraction appear. The first is a "full path" URL wherein the requestor knows the full path to a specific document. In other cases, a default document is invoked (if available) because this is a desirable abstraction.

Using Web browsers as an example somewhat clouds the picture regarding message content. Messages certainly need to be delivered; however, by the time an application receives a message, the delivery information is no longer important — because the message has already been delivered. A developer using the BizTalk Framework assumes that the way the delivery mechanism operates is a total unknown to the application. Once a message has been delivered, apart from providing verification that the recipient is indeed the one the sender designated, the "To" information is of less significance than the content of the message itself.

If a URL were the only information provided to accomplish delivery, only simple exchanges would be possible. At any point, each arrival would indicate that a new instance of an exchange was occurring. This is true because with only one degree of abstraction (location), no notion of an existing instance is possible.

Some say that argument passing does the trick and that the simple formats seen in HTTP GET syntax are sufficient to pass as many arguments as required. While this is true, it puts the delivery logic back into the calling application and requires that each application programmer be aware of the full path to an application instance at all times. In some cases, this is unreasonable and at the very least complicates addressing.

For this reason, in BizTalk Framework 0.81, Microsoft has provided four attributes for managing abstraction. The plans for release 1.0 include a mechanism that further abstracts routing for complex interactions but places larger responsibilities on delivery services that are aware of BizTalk Framework. Since none of these exist today, the routing element provides an interim way of performing routing while at the same time separating out the four degrees of abstraction (location, application, path and instance).

Routing Attribute Definitions

This section defines the purpose 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 and 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 flows that use BizTalk Framework messaging.

LocationType. This is a secondary qualifier on LocationID. Some delivery agents provide support for several types. This attribute eliminates ambiguity 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 used by the final application. The purpose of this attribute is to manage differences between instances of exchanges. It is used whenever a sequence of messages is exchanged and each piece needs to be related to the others logically at either side of a complex interchange.

Call to Action

This version 0.81 specification defines the structures, elements and attributes required to establish the following:

    • BizTalk Framework use. A program should be able to determine that the BizTalk Framework is in use.
    • Document structure. Messages and documents implemented using the BizTalk Framework allow a program to confidently and unambiguously ascertain further information related to a message that is being processed. The structure of a BizTalk Framework message and namespace allows this to happen. The structure allows a program to determine the exact location of the start of the data portion of each BizTalk Framework message.
    • Document type. From the imposed document structure, the document type and design information associated with that type can be determined for any BizTalk Framework message.
    • Document route. Elements and attributes are defined that allow each document to be routed from one application to another without forcing the application programmer to decide on the physical transport mechanism used or to know the physical delivery address. Elements are defined that allow responses to be routed to the original sender, with support for instance identity. These elements may be omitted from BizTalk Framework documents, but are mandatory for BizTalk Framework messages.

Together, the code and specifications form the BizTalk Framework 0.81. Companies that use the BizTalk Framework can incorporate these tags in their own messages. Once these messages and the schemas that describe them have passed a conformance test and are published on the BizTalk.Org Web site, the publishers may call the resulting structure a BizTalk Framework message.

#########

Appendix A: Mandatory BizTalk Framework Tags That Uniquely Identify a Message

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

<Body>

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

That is, within the BizTalk Framework body tag, users place their own message or document structure. A schema defines that message or document. The URI for the schema appears as the value of the "xmlns" attribute of the first element under the BizTalk Framework body element.

URIs 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.

Appendix B: Sample Implementation

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

<BizTalk xmlns="urn:schemas-biztalk-org/biztalk-0.81.xml">
<Route>
<From locationID="111111111" locationType="DUNS"
process="" route="" handle="45"/>
<To locationID="222222222" locationType="DUNS"
process="" route="" handle="93"/>
</Route>
<Body> <PO xmlns="urn:schemas-biztalk-org:fabrikam-com/PurchaseOrder"> Purchase order body document in XML data here </PO>
</Body>
</BizTalk>

 

 


© BizTalk 1999. All rights reserved.