The BizTalk Framework
One of the challenges in architecting HTTP solutions is the possibility that the same exact submission may occur more than once. For example, a request can be received by the server and processed, but dropped network packets may hinder the client from receiving the response. It is possible to write logic to verify that the server never receives a duplicate document, but it is complex and most likely would be implemented at the business level.
Given that this is not desirable, the BizTalk Framework should be considered when using the Biztalk product. BizTalk Framework is a messaging specification based on SOAP that provides functionality to handle the challenges of business communication over unreliable protocols, including reliable delivery. It can be applied by either the Web Services or HTTP Receive Function examples given earlier.
The BizTalk Framework ensures one time delivery of documents over HTTP through the use of BizTags. BizTags are XML tags, attached to the SOAP namespace, and are used by BizTalk server to identify and route documents. The identity BizTag property is shown in Figure 5.
The identity tag is unique to a document submission, and should not be repeated if the same business document is delivered again. The receiving server persists all successfully received documents until they expire. If the server receives a non-expired document that contains the same identity, it should archive the document but not process it. This is analogous to the EDI X12 control number. The X12 standard does not allow for the same organization to submit interchanges with the same control number.
|Figure 5 shows the identity BizTag tag property.
Another advantage to the framework is that it does not require the client to be a BizTalk Framework Compliant (BFC) server to participate in the transaction. If the network hiccup example described earlier occurs, the client still views the transaction as a failure because it did not receive a response (even if it's nothing more that a status of 200). The only requirement though is that the client must resubmit the document to ensure its processing.
Reliable messaging is important, and the BizTalk Framework provides a solution to situations where the type is correct, but the content is rubbish. For example, the Web Service we wrote would take in a string, but that string could be, "<xml>this is garbage</xml>" The client may think that BizTalk successfully processed the request, but BizTalk threw it into its Suspended Queue because it didn't meat its Document Specification.
Which framework to use is an important decision that affects the approaches you'll take when submitting documents via Web Services or HTTP Receive Function. The decision to use BizTalk should hinge on the client applications and their ability to support the BizTalk Framework (i.e. create & manage the required XML overhead).
In evaluating both scenarios for the problem, it is important to determine how much (if any) complementary processing is necessary. Web Service is an effective solution if you need to implement extra requirements (i.e. decoupling, authentication). If your needs are simpler and extra processing is not required, then leveraging BizTalk Server's HTTP Receive function becomes the optimal solution. Finally, the decision to leverage the BizTalk Framework hinges on the calling application. If the client application can support the overhead, the transport layer will be more reliable.