BizTalk Framework 2.0 Draft: Document and Message Specification
`
`10/21/21, 14:09
`
`The Wayback Machine - https://web.archive.org/web/20000815065051/http://msdn.microsoft.com:80/xml/articles/biztal…
` All Products | Support | Search | microsoft.com Home
`---- msdn online
`1
`eb Workshop
`
` Home | Magazines | Libraries | Developer Centers | Resources | Downloads | Search MSDN
` post new comment
` read user comments
` show toc
` index
`
`
`
`
`E.
`4.2 out of 5.
`133 total users have rated this article, result:
`
`Web Workshop | XML (Extensible Markup Language)
`
`•
`BizTalk Framework 2.0 Draft: Document and Message
`Specification
`
`Microsoft Corporation
`June 2000
`Draft Specification
`Summary: This draft specification provides a general overview of the BizTalk Framework 2.0 conceptual architecture,
`including the BizTalk Document and BizTalk Message. It 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.
`Contents
`1. Introduction
`2. Specification Scope and Evolution
`3. References
`4. BizTalk Concepts
`5. BizTalk Document Structure
`6. BizTalk Document Body
`7. BizTalk Document Header Entries
`8. Reliable Delivery of BizTalk Documents
`9. BizTalk Documents with Attachments
`10. HTTP Binding
`11. BizTalk Document Schemas
`1. Introduction
`The growing maturity of Internet-based secure transport protocols, combined with ubiquitous support for these protocols
`across networking, hardware, and software platforms, is enabling businesses to develop new ways to facilitate efficient and
`automated interactions. These interactions can occur between their own internal lines of business; productivity and
`knowledge management applications; the applications used by their customers and partners; and services provided by their
`commercial and corporate providers.
`
`https://web.archive.org/web/20000815065051/http://msdn.microsoft.com/xml/articles/biztalk/biztalkfwv2draft.asp
`
`Page 1 of 28
`
`Zynga Ex. 1014, p. 1
`Zynga v. IGT
`IPR2022-00368
`
`

`

`BizTalk Framework 2.0 Draft: Document and Message Specification
`
`10/21/21, 14:09
`
`•
`
`•
`
`The challenges associated with enabling such efficient, automated interactions between applications across business
`boundaries, and in a cost effective manner, are similar to those associated with enabling them within an enterprise or
`departmental boundary. However, a new dimension of challenges in the areas of security and reliability must be addressed
`in order to communicate with other organizations.
`These challenges of interaction across business boundaries include, but are not limited to, the following:
`Lack of a sufficiently-flexible and rich universal language to specify, package, publish, and exchange both structured
`and unstructured information across application or business boundaries.
`Lack of a flexible and rich universal language to specify, package, publish, and execute transformation rules to
`convert information from one format to the other as application and business boundaries are crossed.
`Lack of middleware-neutral, application-level communication protocols that enable automated interactions across
`application or business boundaries.
`Extensible Markup Language (XML) and XML-based schema languages provide a strong set of technologies with a low
`barrier to entry. These languages enable one to describe and exchange structured information between collaborating
`applications or business partners in a platform- and middleware-neutral manner.
`As a result, domain-specific standards bodies and industry initiatives have started to adopt XML and XML-based schema
`languages to specify both their vocabularies and content models. These schemas are becoming widely published and
`implemented to facilitate communication between both applications and businesses. Wide support of XML has also
`resulted in independent solution providers developing solutions that enable the exchange of XML-based information with
`other third-party or custom-developed applications. Several solution- or middleware/platform-specific approaches have
`been taken to address the lack of middleware-neutral, application-level communication protocols. However, no single
`proprietary solution or middleware platform meets all the needs of a complex deployment environment.
`These proprietary initiatives have generally resulted in customers facing broad interoperability issues on their own. The
`BizTalk™ Framework addresses these interoperability challenges in a platform- and technology-neutral manner. It
`provides specifications for the design and development of XML-based messaging solutions for communication between
`applications and organizations. This specification builds upon standard and emerging Internet technologies such as
`Hypertext Transfer Protocol (HTTP), Multipurpose Internet Mail Extensions (MIME), Extensible Markup Language
`(XML), and Simple Object Access Protocol (SOAP). Subsequent versions of the BizTalk Framework will be enhanced to
`leverage additional XML and Internet-related, messaging-standards work as appropriate.
`It is important to note that the BizTalk™ Framework does not attempt to address all aspects of business-to-business
`electronic commerce. For instance, it does not deal directly with legal issues, agreements regarding arbitration, and
`recovery from catastrophic failures, nor does it specify specific business processes such as those for purchasing or
`securities trading. The BizTalk™ Framework provides a set of basic mechanisms required for most business-to-business
`electronic exchanges. It is expected that other specifications and standards, consistent with the BizTalk™ Framework, will
`be developed for the application- and domain-specific aspects.
`2. Specification Scope and Evolution
`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:
`
`•
`
`https://web.archive.org/web/20000815065051/http://msdn.microsoft.com/xml/articles/biztalk/biztalkfwv2draft.asp
`
`Page 2 of 28
`
`Zynga Ex. 1014, p. 2
`Zynga v. IGT
`IPR2022-00368
`
`

`

`BizTalk Framework 2.0 Draft: Document and Message Specification
`
`10/21/21, 14:09
`
`•
`
`•
`
`•
`
`•
`
`•
`
`•
`
`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
`
`•
`
`•
`
`•
`
`•
`
`•
`
`•
`
`•
`
`•
`
`https://web.archive.org/web/20000815065051/http://msdn.microsoft.com/xml/articles/biztalk/biztalkfwv2draft.asp
`
`Page 3 of 28
`
`Zynga Ex. 1014, p. 3
`Zynga v. IGT
`IPR2022-00368
`
`

`

`BizTalk Framework 2.0 Draft: Document and Message Specification
`
`10/21/21, 14:09
`
`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.
`3. Dependencies
`3.1 Normative Specifications
`Each BizTalk Framework document lists the existing or emerging Internet standards that it is built upon as normative
`references. Some of the content of the normative references may need to be reproduced for expository purposes in BizTalk
`Framework specifications. In all such cases, the normative references are authoritative. Every effort has been made to
`avoid discrepancies between the normative references and their usage in BizTalk Framework specifications. However, if a
`discrepancy is found, the normative reference provides the correct interpretation and the BizTalk Framework specification
`is in need of correction.
`The following specifications are normative for this specification:
`Extensible Markup Language (XML) 1.0
`Simple Object Access Protocol (SOAP) Version 1.1
`Namespaces in XML
`Uniform Resource Identifiers (URI): Generic Syntax
`ISO 8601: Representations of dates and times
`Hypertext Transfer Protocol—HTTP/1.1
`XML Media Types
`MIME Part One: Format of Internet Message Bodies
`MIME Part Two: Media Types
`MIME Part Three: Message Header Extensions for Non-ASCII Text
`MIME Part Four: Registration Procedures
`Content-ID and Message-ID Uniform Resource Locators
`
`•
`
`•
`
`•
`
`•
`
`https://web.archive.org/web/20000815065051/http://msdn.microsoft.com/xml/articles/biztalk/biztalkfwv2draft.asp
`
`Page 4 of 28
`
`•
`
`•
`
`•
`
`•
`
`•
`
`•
`
`•
`
`•
`
`Zynga Ex. 1014, p. 4
`Zynga v. IGT
`IPR2022-00368
`
`

`

`BizTalk Framework 2.0 Draft: Document and Message Specification
`
`10/21/21, 14:09
`
`•
`
`•
`
`•
`
`•
`
`3.2 Non-Normative Specifications
`The following specifications have had an influence on this specification, but the relationship is not foundational and their
`content is not normative for this specification:
`XML-Data Reduced (XDR)
`XML Schema Part 1: Structures
`XML Schema Part 2: Data types
`XML-Signature Syntax and Processing
`3.3 Use of XML Schema Data Types
`This specification uses the type-qualification xsi:type attribute as well as a number of specific data types from the XML
`Schema specifications. These are listed below with explanations. This specification, however, does not mandate the use of
`a specific method for defining XML schemas.
`The xsi:type attribute allows an element to explicitly assert its type in a specific XML document instance. This can be
`used to validate the structure of the element.
`The data type timeInstant represents a specific instant of time. The value space of timeInstant is the space of
`combinations of date and time of day values as defined in section 5.4 of the ISO 8601 standard.
`The uriReference data type represents a URI reference as defined in Section 4 of Request for Comments (RFC) 2396. A
`URI reference may be absolute or relative, and may have an optional fragment identifier.
`A complexType is an element with content that is not a simple type, such as a string or a decimal number; the element
`contains subelements and/or attributes with their own content.
`4. BizTalk Concepts
`4.1 Terminology
`This document uses a set of BizTalk-specific terms, as defined below:
`BizTalk Framework Compliant (BFC) Server. A BFC Server is represented by the set of services providing the
`message-processing functionality defined in the BizTalk Framework specifications.
`Application. An Application is the line-of-business system where the business data or logic are stored and executed.
`An application also includes any additional adapters that may be required to emit or consume Business Documents
`(see below) and communicate with a BFC server.
`Business Document. A Business Document is a well-formed XML document containing business-transaction data.
`This transaction data may represent a purchase order, invoice, sales forecast, or any other business information. One
`or more Business Documents form the body of a BizTalk Document (see below).
`The BizTalk Framework does not prescribe the content or structure (schema) of individual Business Documents.
`The details of the Business Document content and structure, or Schema, are defined and agreed upon by the solution
`implementers.
`
`•
`
`•
`
`•
`
`https://web.archive.org/web/20000815065051/http://msdn.microsoft.com/xml/articles/biztalk/biztalkfwv2draft.asp
`
`Page 5 of 28
`
`Zynga Ex. 1014, p. 5
`Zynga v. IGT
`IPR2022-00368
`
`

`

`•
`
`•
`
`•
`
`•
`
`•
`
`BizTalk Framework 2.0 Draft: Document and Message Specification
`
`10/21/21, 14:09
`
`•
`
`Schema. A Schema is the metadata used to describe the content and structure of a class of XML documents, in
`particular for a class of Business Documents. This formal description is used by application developers to create
`systems that process corresponding Business Documents, or by parsers that validate a Business Document's
`conformance to the Schema at run time.
`Organizations may publish their Schemas in the BizTalk Schemas Library, or through other means.
`Note Schemas for Business Documents do not contain any BizTags, as described in this specification. A schema contains
`only those tags required to support the business transaction, as agreed to by the cooperating business entities. General
`requirements and guidelines for Schema implementations are defined in the BizTalk Schema Guidelines.
`BizTalk Document. A BizTalk Document is a SOAP 1.1 message in which the body of the message contains the
`Business Documents, and the header contains BizTalk-specific header entries for enhanced message-handling
`semantics.
`BizTag. BizTags are the set of XML tags (both mandatory and optional) that are used to specify Business Document
`handling. More precisely, BizTags are elements and attributes defined in this specification and used to construct
`BizTalk-specific SOAP header entries in the BizTalk Document. They are processed by the BFC Server, or by other
`applications facilitating the document interchange.
`BizTalk Message. A BizTalk Message is the unit of wire-level interchange between BFC Servers. BizTalk Messages
`are used to send BizTalk Documents, and any related files, between BFC 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.
`Transport. The actual interchange of BizTalk Messages between BFC servers presupposes a communication
`mechanism that is used to carry Messages physically from the source to the destination business entity. We use the
`term transport to refer to this mechanism. 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. Transport characteristics affect only the transport bindings specified in section 10.
`Attachment. 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.
`4.2 Logical Layering
`The logical application model for the BizTalk Framework is implemented in layers. The layering described here is for
`illustrative and explanatory purposes. As the BizTalk Framework specification definitively specifies only the wire format
`for BizTalk Messages and the protocol for reliable messaging, alternative logical layering may be used, provided it
`supports equivalent functionality, without affecting compliance with this specification. These logical layers include the
`application (and appropriate adapters), the BFC Server, and transport. The application communicates with other
`applications by sending Business Documents back and forth through BFC Servers. Multiple BFC Servers communicate
`with one another over a variety of transport protocols, such as HTTP, SMTP, and Microsoft Message Queue (MSMQ). The
`BizTalk Framework does not prescribe what these transport protocols are, and is independent of the implementation details
`of each.
`
`https://web.archive.org/web/20000815065051/http://msdn.microsoft.com/xml/articles/biztalk/biztalkfwv2draft.asp
`
`Page 6 of 28
`
`Zynga Ex. 1014, p. 6
`Zynga v. IGT
`IPR2022-00368
`
`

`

`BizTalk Framework 2.0 Draft: Document and Message Specification
`
`10/21/21, 14:09
`
`S
`
`■
`
`U
`
`BFC
`ova
`
`us
`
`The application is responsible for generating the Business Documents and any attachments to be transmitted to its peer(s)
`and submitting them to the BFC Server. The responsibility for wrapping the Business Documents in a BizTalk Document
`may rest with either the application or the BFC server, depending on the implementation of the BFC server. The server
`processes the document and any attachments and constructs a BizTalk Message as appropriate for the transport protocol.
`The BFC Server uses information contained in the BizTags to determine the correct transport-specific destination address.
`The server then hands the message to the transport layer for transmission to the destination BFC Server. The interfaces
`between the business application, the BFC Server, and the transport layer are implementation specific.
`5. BizTalk Document Structure
`The following is an example of a simple BizTalk Document.
`<SOAP-ENV:Envelope
` xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
` xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance">
` <SOAP-ENV:Header>
` <dlv:delivery SOAP-ENV:mustUnderstand="1"
` xmlns:dlv="http://schemas.biztalk.org/btf-2-0/delivery"
` xmlns:agr="http://www.trading-agreements.org/types/">
` <dlv:to>
` <dlv:address xsi:type="agr:department">Book Order Department</dlv:address>
` </dlv:to>
` <dlv:from>
` <dlv:address xsi:type="agr:organization">Booklovers Anonymous</dlv:address>
` </dlv:from>
` </dlv:delivery>
` <prop:properties SOAP-ENV:mustUnderstand="1"
` xmlns:prop="http://schemas.biztalk.org/btf-2-0/properties">
` <prop:identity>uuid:74b9f5d0-33fb-4a81-b02b-5b760641c1d6</prop:identity>
` <prop:sentAt>2000-05-14T03:00:00+08:00</prop:sentAt>
` <prop:expiresAt>2000-05-15T04:00:00+08:00</prop:expiresAt>
` <prop:topic>http://electrocommerce.org/purchase_order/</prop:topic>
` </prop:properties>
` </SOAP-ENV:Header>
` <SOAP-ENV:Body>
` <po:PurchaseOrder xmlns:po="http://electrocommerce.org/purchase_order/">
` <po:Title>Essential BizTalk</po:Title>
` </po:PurchaseOrder>
` </SOAP-ENV:Body>
`</SOAP-ENV:Envelope>
`
`https://web.archive.org/web/20000815065051/http://msdn.microsoft.com/xml/articles/biztalk/biztalkfwv2draft.asp
`
`Page 7 of 28
`
`Zynga Ex. 1014, p. 7
`Zynga v. IGT
`IPR2022-00368
`
`

`

`BizTalk Framework 2.0 Draft: Document and Message Specification
`
`10/21/21, 14:09
`
`•
`
`•
`
`This BizTalk Document consists of a standard SOAP 1.1 message that contains the following:
`An application-specific Business Document (in this case a book purchase order), with its own application-defined
`XML namespace, carried in the body of the SOAP message.
`BizTalk-specific <delivery> and <properties> SOAP header entries, constructed using BizTags defined in
`standard BizTag namespaces, with schema and semantics defined in this specification.
`In general, the body of the SOAP message constituting a BizTalk Document contains several related Business Documents,
`and the header of the SOAP message contains several BizTalk-specific (and potentially other) header entries. The use of
`the SOAP-ENV:mustUnderstand attribute with a value of "1" implies (in accordance with the SOAP 1.1 specification)
`that the destination business entity receiving this Document must understand and correctly process the header entries so
`attributed, or if the header entry is not understood, the processing of the Document must be terminated with failure.
`All BizTags are defined within standard BizTag namespaces with URIs derived by extension from the prefix
`http://schemas.biztalk.org/btf-2-0/. The scope of semantic significance for the BizTag namespaces is always confined to
`the header of the outermost BizTalk Document. If a BizTalk Document is carried whole in the body of another BizTalk
`Document, the BizTags in the inner document are "dormant" and ineffective—they are treated as business data for the
`purposes of processing the outer Document.
`It is worth noting that the <to> and <from> routing tags, described in more detail below, often use business-entity names
`for source and destination addressing, rather than transport addresses such as HTTP URLs. The form and interpretation of
`the address content is indicated by the xsi:type attribute. The BizTalk Document structure and function are independent of
`the transports over which the Documents are carried.
`6. BizTalk Document Body
`The <Body> element of the SOAP message that constitutes a BizTalk Document contains the Business Documents being
`carried. In general, a BizTalk Document may carry a set of related Business Documents (for instance, a purchase order and
`a shipper's name and address for shipping that order).
`Related Business Documents often have shared content. SOAP has a straightforward mechanism for encoding data
`targeted by multiple references; it uses XML ID attributes and relative URIs. Consider a simple elaboration of the
`purchase order example above in which both the purchase order and the shipping information reference information about
`the book. The <Body> element of the following BizTalk Document shows how this could be expressed using SOAP
`encoding rules.
`<SOAP-ENV:Envelope
` xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
` xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
` xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance">
` <SOAP-ENV:Header>
` <!-- headers omitted for brevity -->
` </SOAP-ENV:Header>
` <SOAP-ENV:Body>
` <po:PurchaseOrder xmlns:po="http://electrocommerce.org/purchase_order/">
` <po:item href="#theBook"/>
` <!-- and other purchasing information -->
` </po:PurchaseOrder>
`
` <ship:shippingInfo xmlns:ship="http://electrocommerce.org/shippingInfo/">
` <ship:content href="#theBook"/>
` <!-- and other shipping information -->
` </ship:shippingInfo>
`
`https://web.archive.org/web/20000815065051/http://msdn.microsoft.com/xml/articles/biztalk/biztalkfwv2draft.asp
`
`Page 8 of 28
`
`Zynga Ex. 1014, p. 8
`Zynga v. IGT
`IPR2022-00368
`
`

`

`BizTalk Framework 2.0 Draft: Document and Message Specification
`
`10/21/21, 14:09
`
` <book xmlns="http://electrocommerce.org/bookInfo/" id="theBook" SOAP-ENC:root="0">
` <Title>Essential BizTalk</Title>
` <!-- and other book information -->
` </book>
` </SOAP-ENV:Body>
`</SOAP-ENV:Envelope>
`This example also illustrates a problem that occurs when this technique is used. We would like the destination business
`entity to view this BizTalk Document as containing two Business Documents: the purchase order and the shipping
`information. However, the <Body> of the SOAP message contains three child elements. We need a way to distinguish the
`Business Documents from the elements that appear as direct children of <Body> because they are shared via multiple
`references.
`SOAP provides the SOAP-ENC:root attribute as a method for signaling that an element is not an independent entity.
`Every immediate child of the <Body> element in a BizTalk Document is a contained Business Document unless that child
`carries the SOAP-ENC:root attribute with a value of "0".
`7. BizTalk Document Header Entries
`This section describes the four BizTalk-specific SOAP header entries that may occur in a BizTalk Document. They are
`concerned with Document routing and delivery, Document identification and other properties, a catalog of Document
`contents and attachments, and tracking of the business process context of which the Document is a part. The following
`table lists the four BizTags used to mark the header entries and their properties. Each header entry is described in more
`detail in the following sections, and schemas for the corresponding elements are provided in the appendix.
`
`Tag Name
`delivery
`
`Properties
`
`Manifest
`
`Process
`
`Mandatory
`yes
`yes
`no
`no
`
`Kind
`element
`element
`element
`element
`
`Type
`complexType
`
`complexType
`
`complexType
`
`complexType
`
`Occurs
`once
`once
`once
`once
`
`7.1 Document Routing and Delivery
`Document routing is specified by a SOAP header entry marked by the <delivery> BizTag. This entry contains
`information about the source and destination of the BizTalk Document. There may also be a section that provides
`information required for reliable delivery. An extended version of the delivery header entry from the initial BizTalk
`Document example, including a reliability section, is shown below:
` <dlv:delivery SOAP-ENV:mustUnderstand="1"
` xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
` xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
` xmlns:dlv="http://schemas.biztalk.org/btf-2-0/delivery"
` xmlns:agr="http://www.trading-agreements.org/types/">
` <dlv:to>
` <dlv:address xsi:type="agr:department">Book Order Department</dlv:address>
` </dlv:to>
` <dlv:from>
` <dlv:address xsi:type="agr:organization">Booklovers Anonymous</dlv:address>
` </dlv:from>
` <dlv:reliability>
`
`https://web.archive.org/web/20000815065051/http://msdn.microsoft.com/xml/articles/biztalk/biztalkfwv2draft.asp
`
`Page 9 of 28
`
`Zynga Ex. 1014, p. 9
`Zynga v. IGT
`IPR2022-00368
`
`

`

`BizTalk Framework 2.0 Draft: Document and Message Specification
`
`10/21/21, 14:09
`
` <dlv:sendReceiptTo>www.we-love-books.org/po/confirmations</dlv:sendReceiptTo>
` <dlv:receiptRequiredBy>2000-05-14T08:00:00+08:00</dlv:receiptRequiredBy>
` </dlv:reliability>
` </dlv:delivery>
`As noted in the context of the initial example, although the source and destination are specified as names of business
`entities marked by the <address> BizTag, the selection of transports and transport endpoints, over which the BizTalk
`Document is carried, often occurs separately between the business entities involved. It is entirely possible that multiple
`transports and transport endpoints are available for the communication and that they will change over time, without
`changing the names of the business entities (in <address>) and the structure of the BizTalk Documents exchanged
`between the entities. The exact routing logic used to deliver the BizTalk Document once it reaches the BFC server that is
`associated with the destination business entity is implementation dependent.
`Understanding and processing the <delivery> header entry and all its contents at the recipient BFC server is always
`mandatory during successful processing of a BizTalk Document. The encoding of the <delivery> element must always
`contain the SOAP-ENV:mustUnderstand="1" attribute to reflect this. The following table lists the BizTags used to
`construct the subelements of the <delivery> header entry and their properties.
`
`Tag Name
`to
`
`from
`
`reliability
`
`Mandatory
`yes
`yes
`no
`
`Kind
`element
`element
`element
`
`Type
`complexType
`
`complexType
`
`complexType
`
`Occurs
`once
`once
`once
`
`The <to> tag contains the specification of the destination business entity to which the BizTalk Document is to be
`delivered. This element contains exactly one occurrence of an <address> subelement.
`The <from> tag contains the specification of the source business entity from which the BizTalk Document originates. This
`element contains exactly one occurrence of an <address> subelement.
`The <address> tag contains the identification of a business entity in string form. The <address> element has a required
`xsi:type attribute. The value of the xsi:type attribute signifies the category of the address as well as the permissible
`structure of the string form of the address. Several categories, including organization name and URI reference, are used in
`examples in this specification.
`The <reliability> tag is an optional element that contains the information necessary to perform reliable delivery of the
`enclosing BizTalk Document. If the <reliability> element is present, (the BFC server at) the destination business entity
`is required to send a receipt back to the given URL upon receiving and accepting the BizTalk Document. The Document-
`handling behavior related to this element and the structure and content of receipts is described in more detail in section 8.
`The <reliability> element contains two subelements listed in the table below.
`
`Tag Name
`sendReceiptTo
`
`receiptRequiredBy
`
`Mandatory
`Yes
`Yes
`
`Kind
`element
`element
`
`Type
`uriReference
`
`timeInstant
`
`Occurs
`Once
`Once
`
`The <sendReceiptTo> tag contains a URL that specifies the transport address (typically at the source business entity) to
`which a receipt for the BizTalk Document must be sent.
`
`https://web.archive.org/web/20000815065051/http://msdn.microsoft.com/xml/articles/biztalk/biztalkfwv2draft.asp
`
`Page 10 of 28
`
`Zynga Ex. 1014, p. 10
`Zynga v. IGT
`IPR2022-00368
`
`

`

`BizTalk Framework 2.0 Draft: Document and Message Specification
`
`10/21/21, 14:09
`
`The <receiptRequiredBy> tag contains a time instant that specifies the absolute time by which a receipt for the delivery
`and acceptance of the BizTalk Document must be received by (the BFC server at) the source business entity. Failure to
`receive the receipt in time will typically initiate error-recovery behavior at the source. See the Explanatory Note associated
`with the <expiresAt> tag for a discussion of the merits and pitfalls of the use of absolute time instants in this context. See
`section 8 for details of the reliability protocol, including the semantics of this deadline.
`7.2 Document Identification and Properties
`Document identity information and other properties are specified by a SOAP header entry marked by the <properties>
`BizTag. The properties header entry from the initial BizTalk