BizTalk: E-Commerce the Microsoft Way I (3/3) - exploring XML

BizTalk: E-Commerce the Microsoft Way I

BizTalk Messages

A BizTalk Message is the unit of wire-level interchange between BizTalk Servers. BizTalk Messages are used to send BizTalk Documents, and any related files, between BizTalk Servers. A BizTalk Message must always contain a primary BizTalk Document that defines the semantics of the Message within the BizTalk Framework. It may in addition contain one or more attachments (see below), including well-formed XML documents, some of which may themselves be BizTalk Documents. BizTalk Documents carried as attachments are treated just like any other XML documents and have no special significance for the semantics of the BizTalk Message. The structure of a BizTalk Message is dependent on the transport being used to carry the message and often includes transport-specific headers.

Message Transport

The actual interchange of BizTalk Messages between servers presupposes a communication mechanism that is used to carry Messages physically from the source to the destination business entity. Transports used in this context will vary widely in their characteristics, ranging from simple datagram and file transfer protocols to transfer protocols such as HTTP and SMTP, and sophisticated, message-oriented middleware. This specification does not differentiate between transports based on their capabilities.

Endpoints and Addresses

An endpoint designates a BizTalk Framework compliant source or destination of a BizTalk Message. An address is the location of an endpoint, resolvable in context for the purposes of message transport and delivery.

Attachments

Attachments are generally non-XML files or other related information that is not transmitted as a Business Document within the body of the BizTalk Document. These may be related images, large compressed files, or any other information format or content that is not an appropriate Business Document. Attachments may be carried within the BizTalk Message enclosing the BizTalk Document, or they may be external to the Message, and simply referenced within the Document.

BizTalk specifies the following:

• A standard way to associate a primary BizTalk Document with one or more attachments in a multipart MIME structure for transport.
• The relationship between the MIME structure for attachments and the <manifest> header entry in the primary BizTalk Document.

Most Internet transports are capable of transporting MIME encoded content.

Reliable Delivery of BizTalk Documents

BizTalk facilitates asynchronous document exchanges involved in e-commerce and Enterprise Application Integration, where specific delivery guarantees and error detection and reporting are necessary for integration of business functions across domain boundaries. High-performance-messaging middleware solutions for the Internet are emerging and should be used for this purpose when available. However, given the broad scope of deployment scenarios for BizTalk Framework-based application integration, and the continued use of transports with lower guarantees of service, it is important to provide a simple standard solution for reliable delivery of BizTalk Documents that can be easily implemented by BizTalk servers. Furthermore, standard business processes require confirmation not just of delivery and physical acceptance of a message, but also separately of verification of message content and intent to perform the business action requested.

The solution for both these requirements is based on two simple notions:

• Document receipts.
• Idempotent delivery.

The overall purpose is to ensure a defined outcome for BizTalk Document delivery, acceptance and processing commitment. The following points summarize the ideas on which the functionality described here is based:

• Delivery and commitment receipts provide a way for the source business entity to assure itself that the BizTalk Document was received and accepted (delivery receipt), or inspected for correctness of content and committed for processing (commitment receipt), using the identity for correlation.
• Given the possibility of multiple transmissions of the same BizTalk Document due to retry, the destination business entity may apply idempotent delivery rules to detect and eliminate duplicate Documents, again using the identity for correlation.
• If the source business entity does not receive a delivery receipt within the timeout period specified in the <sendBy> sub-element in the <deliveryReceiptRequest> element, a delivery failure report will be generated and corrective action taken.
• If the source business entity does not receive a commitment receipt within the timeout period specified in the <sendBy> sub-element in the <commitmentReceiptRequest> element, this is treated as being equivalent to receiving a negative commitment receipt with no additional detail.
• Note that there is a small but finite possibility that the Document will be delivered to the destination business entity, verified and processed and a delivery and/or commitment failure report will nevertheless be generated at the source business entity, since any/all receipts may be lost due to transport failure.

Securing BizTalk Documents and Messages

Business processes very often require the ability to secure individual messages for authentication, integrity, non-repudiation or privacy. Transport-level mechanisms such as Secure Socket Layer (SSL) are sufficient for single-hop privacy and authentication but do not satisfy requirements for signing and encryption of individual messages and message parts for multi-hop transport and routing which is very common in business scenarios. The BizTalk Framework supports S/MIME version 3 for securing BizTalk Messages and their parts.

Conclusion

This would not be a Microsoft framework without a subsequent implementation suite, and BizTalk is no exception: The BizTalk server and the BizTalk.org Web site are an implementation of and a repository for the framework, respectively. We'll look at them in our next article, bye for now!

Acknowledgements: This article contains information from the Microsoft Developer Network (MSDN).

Produced by Michael Claßen

URL: https://www.webreference.com/xml/column47/3.html
Created: Jan 07, 2002
Revised: Jan 07, 2002