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