Datasheet

document is mapped into another. Once the business analyst has defined this process, a developer

can create a BizTalk application that implements it. This includes things such as choosing adapters,

defining the data mappings for the business documents that will be used, and creating the

orchestrations necessary to implement the process logic. An administrator can then deploy the BizTalk

application, set up communication among the systems, and perform other tasks. All three roles—

business analyst, developer, and administrator—are necessary to create and maintain BizTalk Server

2006 R2 solutions.

Figure 2 shows a simple example of how BizTalk Server 2006 R2 can be applied to an integration

problem. In this scenario, an inventory application, perhaps running on an IBM mainframe, notices that

the stock of an item is low and so issues a request to order more of that item. This request is sent to a

BizTalk Server 2006 R2 orchestration (step 1), which then issues a request to this organization’s ERP

application requesting a purchase order (step 2). The ERP application, which might be running on a

Unix system, sends back the requested PO (step 3), and the orchestration then informs a fulfillment

application, perhaps built on Windows using the .NET Framework, that the item should be ordered

(step 4).

Figure 2: BizTalk Server 2006 R2 can be used to automate a business process that spans multiple

applications on different platforms.

In this example, each application might communicate using a different protocol. Accordingly, BizTalk

Server 2006 R2 must be able to talk with each one in its native communication style, using the

appropriate adapter. Also, notice that no single application is aware of the complete business process.

The intelligence required to coordinate all of the software involved is implemented in the BizTalk Server

2006 R2 orchestration.

How does this change in a service-oriented world? One possibility is that the way applications can be

accessed becomes more consistent, with Web services a common choice. Another change is that the

role of a central integration server might be viewed somewhat differently. A popular term for an

integration technology in a service-oriented world is enterprise service bus (ESB), and BizTalk Server

2006 R2 can be used in this style. To help with this approach, Microsoft provides guidance and

reference architectures for ESB functionality.

Whether or not an organization takes a service-oriented view, managing integration technology is

essential. To allow this, BizTalk Server 2006 R2 includes the BizTalk Administration console to let

developers and administrators monitor and manage the product. And to help navigate the thicket of

logon technologies that diverse applications might use, BizTalk Server 2006 R2 includes an Enterprise