As we progress through this section, bear in mind that in order to achieve application integration, all messages must pass through BizTalk Server before they reach their destination. Remember that BizTalk Server is a centralized means of routing and translating documents. Therefore a message transfer actually consists of two steps:

1. A message is sent to BizTalk Server

2. BizTalk Server sends the message on to another application

We shall start this section by introducing a few BizTalk Server-specific definitions associated with messaging. These will be used in later chapters. Then we will look at how BizTalk Server actually sends and receives messages, and we will finish by discussing the advantages of queueing messages.

Organizations

An organization in BizTalk is a fairly broad concept. It can encompass a whole business, or a distinct entity within a business. Remember that earlier in the chapter we described a business process (workflow) as a series of islands of automation linked by the exchange of documents? If we continue with this theme, then each island will be represented in BizTalk as an organization.

The Home organization is the object that represents your business in BizTalk; it is created for you by BizTalk Server automatically. You can rename it to the actual name of your business to make it easy to identify in the workflow.

In a simple model where a company is sending a document to a trading partner, the partners and organizations exactly correspond. In more complex situations involving multiple applications within a single company, it is better to think of each entity in control of each application as an organization.

BizTalk can select a channel (explained below) for message delivery based on the organizations involved, together with the type of the document being sent. You must be sure that your definition of each organization is sufficiently detailed to uniquely identify the proper receiving party. The organization is therefore the point of contact for the exchange of messages.

Document Definitions

The document definition refers to the type of message document that is processed by BizTalk Server. It provides a pointer to a particular document specification, which is data about what the file can contain - hence it is meta data (data about data). Note that any particular specification can be used in any number of document definitions, and any particular document definition can be used in any number of channels.

BizTalk supports a variety of message types, such as XML and EDI. We shall see later that the navigation pane of the Document definitions section of Messaging Manager contains a listing of all the document specifications known to a particular BizTalk Server installation. This information is maintained in the BizTalk database.

Envelopes

Envelopes are conceptually similar to real-world, paper postal envelopes. When you want to send a document to a partner, you will specify an envelope in which the document travels. Unlike real-world envelopes however, BizTalk associates a particular envelope with a particular type of document.

You should note that envelopes are not strictly required for XML-format messages. Because we tag data in XML, BizTalk can look at the root-level tag to determine document type. However, they are critical in flatfile formats: the envelope contains information about the document that BizTalk needs to route the message. If you submit a message with routing information based on the sending and receiving organizations, Messaging Services must find a channel to use based on the organizations and the document type. Without an envelope, BizTalk would be unable to determine the document type for non-XML formats.

The Envelopes section of Messaging Manager permits management and creation of envelopes for BizTalk documents.

Ports and Distribution Lists

A port is a set of properties that directs how documents are enveloped, secured, and transported to a designated destination organization or application.

By specifying a port to use, two applications can exchange a message without either of them needing to know how the message is transmitted (protocol) or where the message is delivered to (the end location). The applications do not need to involve themselves in actual message delivery either; that is the responsibility of Messaging Services. At runtime, Messaging Services consults the properties of the named port to determine how and where to send the message it has been given. By removing responsibility for message transmission from the applications themselves, the applications can remain unchanged even when the end location or protocol changes.

For example, an application might start out using MSMQ - naming a specific queue in the process - and later move to HTTP when it is web-enabled. The application's port would initially specify MSMQ and the designated port, then would shift to HTTP and, say, a particular ASP page on a particular server as the new endpoint. So long as the port definition is updated in the Messaging Manager, the sending application would not notice the change.

There will be occasions when we need to broadcast a particular message to several applications. Each application or organization that should receive a message needs a port designated for message delivery. It would be unwieldy to have to configure one-to-one relationships with each recipient, so Messaging Manager allows you to select a collection of ports and give them a name. This named collection is known as a distribution list.

Distribution lists are also termed port groups in the configuration object model that we will explore later in this book.

At runtime, Messaging Services notes the use of a distribution list and sends the submitted message to each port in the list. Note that each port may potentially use a different protocol, so sending a message to a distribution list can result in multiple transmissions over differing protocols.

Channels

A channel is a set of properties that designates the source of documents, and also defines specific processing steps that must be performed by BizTalk Messaging Services before a document is delivered to the destination.

The destination is designated by the messaging port. By themselves, ports and message specifications are not specific to any particular message exchange in the workflow, and so they can be reused whenever necessary. By contrast, when associated with a particular port and message specification, channels can be used to implement a specific message exchange within the workflow.

Channels are an important link between the low-level configuration details of Messaging Services, and the high-level workflows of the XLANG Scheduler. Specific actions within a XLANG schedule are designated by naming a channel. At runtime, when XLANG Scheduler attempts to execute a particular action, it invokes the channel, thereby bringing Messaging Services into play to actually send the message.

Transactions

A transaction is a set of actions that are grouped together into one discrete unit. When the transaction is implemented at runtime, if all the actions are carried out successfully, the transaction succeeds. If any of the actions cannot be carried out, the transaction fails and the data flow is "rolled back" to the beginning of the transaction.

Why should we need to employ such a system? Well, there are many occasions where the failure of one action has an important knock-on effect to other actions. For example, say we had a system where money was being transferred from one bank account to another. Here we would need (a minimum of) two actions:

1. Debit the original account

2. Credit the new account

We could place these actions in the workflow, but consider what would happen if the attempt to credit the new account failed. We would be left with a situation where the original account had been debited but the new account has not been credited: money is lost because of the error.

On the other hand, if we tie the two actions together in a transaction, the transfer will only occur if both actions are successful; otherwise the workflow will be rolled back to the start of the transaction. In both cases no money is lost. We will learn more about transactions in Chapter 2.

Message Transfer

BizTalk Server uses two techniques for transferring messages between applications:

• Open Internet protocols
• Windows-specific communications

Let's now explore both of these options more closely.

Open Protocols

The Web relies on open (public) protocols for communication between applications. Any product interested in performing application integration over the public Internet, therefore, must support these protocols in order to support common strategies for implementing Internet applications. Intranet applications are becoming common in business process integration situations, and they often use these protocols too.

It should not be surprising, therefore, that BizTalk Server supports the major web protocols for the transport of data interchange documents between applications. These are the protocols BizTalk Server supports for communications:

• Simple Mail Transport Protocol (SMTP) - communications via e-mail
• Hypertext Transfer Protocol (HTTP) - the communications mechanism used by web pages and applications (ASP, CGI, and so on)
• Secure Hypertext Transfer Protocol (HTTPS)- a version of HTTP that uses the Secure Sockets Layer (SSL) to encrypt traffic passing between the client and server

Of the three, HTTP and HTTPS permit the most interactive form of communication. It is possible to implement an application as an ASP page or CGI script and connect it directly to BizTalk Server. When a message is received for the HTTP-based application, BizTalk Server makes a request of the designated page or script. The results of executing the script can, in turn, be a reply message sent through BizTalk Server to the sender.

SMTP requires that a script be run upon receipt of the e-mail message. This script can perform the desired application functions or use other mechanisms to invoke applications. Because of the nature of e-mail, SMTP communications may not be immediately responsive.

Continued...