The Fundamentals of Messaging

It might be confusing for some to understand how BizTalk Messaging is different from, say, Microsoft Exchange or some other typical e-mail application. The primary difference between the two is that Microsoft BizTalk Server can send and receive documents using multiple protocols and almost any document type imaginable, whereas applications such as Exchange expect a particular type of document to be delivered over a predetermined protocol—for example, SMTP. BizTalk Server 2002 offers more flexibility in that it can wait for data to be delivered from the Internet “cloud” and then, based on information in the document itself, determine how to process it. This is not to say that BizTalk can't take advantage of direct communication via the likes of Distributed COM (DCOM) or Microsoft Message Queues (MSMQ). However, BizTalk does not require a tightly coupled interface, which makes it appealing and important in an enterprise Business to Business (B2B) or Application to Application (A2A) solution.

BizTalk Server 2002 provides two ways to configure the properties required for the exchange of documents between trading partners (B2B) and enterprise applications (EAI/A2A). One way is to use the BizTalk Messaging Manager (see Chapter 7), which is a wizard-driven interface for configuring trading relationships between applications; the other is the BizTalk Messaging Configuration Object Model (see Chapter 19, “The BizTalk Messaging Configuration Object Model”), which enables developers to configure BizTalk Messaging solutions programmatically. Regardless of which method you choose, the ultimate goal is to configure the messaging engine to manage the exchange of business data between organizations and applications in those organizations.

Figure 6.1 shows an example of a basic message flow between two organizations, one of which is using BizTalk Messaging. Notice that the data sender is immersed in an Internet “cloud.” In many cases, BizTalk Server Messaging receives data from an anonymous source and then makes processing decisions based on data contained within the document. BizTalk Server also can receive data via defined MSMQ queues or URLs, which help the server determine who is sending the data, what its purpose is, and where its final destination and document format should be.

BizTalk Server supports most standard Internet protocols including HTTP, HTTPS, SMTP, and the file system. To exchange data between two applications or organizations, both the sender and receiver must agree on the data formats they are exchanging. After you have identified the data formats that each expects, the sender simply needs to know where to send the data, a URL, e-mail address, or something similar. If you happen to be the data receiver, you need to know how to interpret that data and then architect and design your system to receive and process the documents in ways that are non-problematic for your organization and your business partners.

So let's talk about protocols. At the lowest level, BizTalk can accept documents from MSMQ, the file system, or the IInterchange COM interface. For instance, you could set up BizTalk Server to “sniff” a particular file location using the BizTalk Server receive functions. These receive functions monitor named queues or file locations for arriving documents and process them accordingly as specified by properties defined using the BizTalk Server Administration Console. You also could create an ASP Web site that would allow trading partners to POST their documents to you over HTTP or HTTPS. (We will do this in Chapter 7.) After the document is submitted to the correct URL, the ASP code invokes the IInterchange interface using the submit or submitSync methods, which causes the document to begin processing according to the configuration specified by the messaging engine.

The possibilities are great, and the configurations will vary to a large degree. Solutions will be made on a case-by-case basis, due to the many factors that make B2B and A2A so interesting.