2. Specification Scope and Evolution

[Previous] [Next]

This specification provides a general overview of the BizTalk Framework conceptual architecture, including the fundamental notions of BizTalk Document and BizTalk Message. It then provides detailed specifications for the construction of BizTalk Documents and Messages, and their secure transport over a number of Internet-standard transport and transfer protocols, as described below.

BizTalk Documents follow a number of rules for structure and content in order to provide rich functionality and predictable semantics. This specification describes the following aspects of BizTalk Documents and their semantics:

• Overall structure of BizTalk Documents.
• BizTalk headers for document routing, properties, catalog, and process management.
• Structure and handling of BizTalk Documents that require reliable delivery.

When implementing solutions using the BizTalk Framework, specific transport, encoding, and security mechanisms must be used to secure and deliver messages. This specification describes the following mechanisms and aspects of BizTalk Message encoding and transport:

• Transport bindings for Internet protocols (HTTP only; Simple Mail Transfer Protocol (SMTP), and File Transfer Protocol (FTP) to be added).
• MIME-based transfer encoding and attachment packaging.
• Signatures and encryption based on S/MIME and Public-Key Cryptography System (PKCS) (to be added).

This specification is intended to define messaging interaction between BizTalk Framework 2.0 Compliant servers, referred to as BFC servers in this specification.

2.1 Relationship to BizTalk Framework 1.0

The BizTalk Framework 2.0 specification is a major revision of the BizTalk Framework 1.0 specification. BizTalk Framework 2.0 includes the following new features:

• Transport bindings (HTTP only; SMTP, and FTP to be added).
• Reliable message delivery.
• MIME encoding for attachments.
• Security based on S/MIME and PKCS (to be added).

In addition, BizTalk Framework 2.0 has been influenced by many recent standards efforts including, but not limited to, the following:

• SOAP Version 1.1
• XML Schema Part 1: Structures
• XML Schema Part 2: Data types
• XML-Signature Syntax and Processing

The influence of SOAP 1.1 is most pervasive since BizTalk Framework 2.0 is an extension of SOAP 1.1, whereas BizTalk Framework 1.0 was "pre-SOAP." In addition, the opportunity for a major revision was used to rationalize the semantics, naming, and structure of many BizTags in the light of experience and the requirements of the new features in this specification.

One of the goals of BizTalk Framework 2.0 is to sufficiently explain wire-level behavior so that it's useful as the basis for interoperation among compliant servers. The semantics of many BizTags has been defined much more specifically than in BizTalk Framework 1.0. The structure and content of BizTalk Documents described in BizTalk Framework 1.0 have been preserved wherever possible, but precise semantics and consistency with standards have been given higher priority in order to provide a solid foundation for the future.

2.2 Versioning Model

BizTalk Framework 2.0 follows SOAP 1.1 in not defining a traditional versioning model based on major and minor version numbers. The version is implied by the namespace URIs used to qualify the BizTalk-specific header entries defined in this specification. Normal SOAP 1.1 rules for the SOAP-ENV:mustUnderstand attribute imply that if the header entries that are required to be understood carry the wrong namespace or are deemed ill-formed in some other fashion, the BFC server should respond with a SOAP-ENV:mustUnderstand fault.

In the context of the HTTP binding specified in section 10, this fault indication may be returned in the HTTP response. However, if the message is processed asynchronously, the HTTP response will be 202 accepted and the fault should be returned asynchronously, whenever possible. See section 10 for further discussion of transport protocol binding.