What Is BizTalk Orchestration?

This section lays the groundwork for subsequent sections and chapters—that is, it covers enough material for you to recognize the connections between the terms and concepts that are inevitably intertwined. After all, we are talking about an integration framework.

Purpose

Traditionally, systems integration solutions have been, and continue to be to some extent, extensively hand-crafted and difficult to maintain. The systems integrator has had to contend with understanding and then translating an analyst's view of a business process into a working system.

Not only must the systems integrator comply with the logic of the business flow but also must address real systems issues, such as security, transactions, communication protocols, scalability, resource allocation, and so on.

BizTalk Server comes to the rescue by providing a system integration platform that leverages native services from the Windows platform, such as COM+ application services and messaging. This server platform is broadly segmented into two areas—BizTalk Messaging Services and BizTalk Orchestration Services. Although the entire BizTalk Server platform is intended to simplify systems integration efforts, BizTalk Orchestration Services, in particular, are useful for designing and implementing the business processes. Tools permit composition of business flows for an easy, evolutionary maintenance of the system.

Let's look at the features and the major pieces of BizTalk Orchestration.

Features

The design of a business process is captured in a BizTalk Orchestration drawing. This drawing is then compiled into a form that can be run by a runtime engine.

A BizTalk Orchestration drawing separates the definition of the business process from its implementation. This allows for a twofold benefit. The business analyst can focus on describing the workflow without being bogged down with implementation details, and the systems integrator can focus on implementation details, possibly reusing the implementation pieces even as workflows change.

With hooks into COM components, message queuing, and BizTalk Messaging Services, the BizTalk Orchestration workflows can communicate with other applications, without mandating compliance with any specific platform or custom protocols. This opens the door for truly any-to-any integration. The BizTalk Server ships with support for exchanging messages via SMTP, HTTP, HTTPS, MSMQ, and files. In addition, you can define your own components, called Application Integration Components (AICs), to process messages or have other applications post messages to BizTalk. Although the FTP protocol is not natively supported at this time, you can use either integrated third-party products (see the product Web site) or standalone third-party FTP services to deliver files to the file system.

With BizTalk Orchestration drawings, you can express the rich, dynamic interactions that exist between two organizations or applications. For example, a workflow action can bind to a specific remote application based on the execution history of a potentially long running business partner interchange.

Business processes can be easily refined, evolved, and assembled from simpler blocks—a clear advantage for maintainability.

The BizTalk Orchestration drawings allow you to express process concurrency and synchronization, branching, and error handling as part of your integration solution. Rich support for transactions, both long-lived and short-lived, also are included. A BizTalk Orchestration drawing is compiled before it is run by the runtime engine; this helps to detect simple design errors early on.

The BizTalk Orchestration engine supports dehydration. Dehydration gives the server a way to durably save the execution state of a workflow. By dehydrating workflows that are waiting and not performing any useful work and rehydrating them later only when the conditions are ready for them to continue, BizTalk Orchestration can support many workflows.

Terminology and Services

BizTalk Orchestration workflows are described using the XLANG language—a language developed specially to express components, flows, and structure of workflows. This language is based on the XML technology. The workflow expressed this way is called an XLANG schedule.

The XLANG schedule is an executable process; however, it needs a special service to execute it. This service is called the XLANG scheduler engine (or sometimes just the scheduler or the engine). When an XLANG schedule is run, the engine creates an instance of the schedule. Hence, many instances of an XLANG schedule may be running at a given time, each in a different state of execution.

The gamut of services needed to support the creation and running of an XLANG schedule, including the configuration and maintenance of the schedule are provided by BizTalk's Orchestration Services. One of the key features alluded to earlier is the engine's support for long-running business processes. A key capability of BizTalk Orchestration Services is dehydrating and rehydrating instances of XLANG schedules. This means that if the instance of a schedule is not performing any work, and is in a quiescent state waiting for an event, then the entire internal state of the schedule is automatically persisted to disk to conserve precious system resources. This is called dehydration of a schedule.

The reverse process is that of rehydration. Rehydration is performed when BizTalk Orchestration Services determine that conditions have changed to allow a dehydrated schedule to perform new work. This rehydration is also done automatically. When this occurs, a new schedule is created and its last-known state loaded from disk to conform to what it was at the time it was dehydrated.

Four implementation technologies are supported by BizTalk Orchestration. Two are component technologies, and two are messaging technologies. The components include COM or COM+ components built using any COM-aware Windows programming language and Windows Script Components. The messaging support is provided by Microsoft Message Queuing (MSMQ) and the BizTalk Messaging Services.

The XLANG schedules are designed using the BizTalk Orchestration Designer. The designer is used to construct XLANG schedule drawings. These drawings then are compiled into an XLANG schedule before they can be executed. The schedules must be debugged and tested before deployment. Configuration and monitoring tools for schedules are also available.

The Orchestration Persistence database stores the structure of XLANG schedules, the state of currently active schedule instances, and the state of dehydrated instances. The persistence database also contains the precise state of a schedule instance, both before and after a transaction. This facilitates the correct recovery from failures. Configuring the persistence database is covered in Chapter 11, “XLANG Orchestration Engine.”

With this general introduction to BizTalk Orchestration, we can now jump into the topic of drawing an XLANG schedule.

XLANG Schedule Drawings—a Preview

The BizTalk Orchestration Designer is used to build an XLANG schedule drawing. The designer is really an extension of the Microsoft Visio 2000 drawing tool. Although this fact is only an implementation detail, we mention it to provide you an idea of what to expect in the designer. The designer provides specialized flowchart shapes and drawing sheets to enable you to express your business processes for use within BizTalk. Figure 9.1 shows a simple business process used in the tutorial that ships with the product. This schedule is located at Program FilesMicrosoft BizTalk ServerTutorialScheduleSolutionBuyer1.skv and has been used at many points in the chapter to illustrate BizTalk Orchestration concepts. The BizTalk Orchestration Designer also works with Visio 2002 if you install BizTalk Server 2002 service pack 1a.

Error! Reference source not found. Figure 9.1 shows the Flowchart stencil window docked to the left and the Implementation stencil window docked to the right. Each stencil window displays shapes you can use within your XLANG schedule drawing. These shapes can be dragged onto the drawing surface. The shapes will be described in much more detail as you progress through the chapter.

The center panel shows the business process itself. The implementation is not visible, but you would see those things if you were to scroll to the right. The menu and the toolbars are at the top. The two toolbar buttons you will use often are the arrow button (shown pressed) and the Connector Tool next to it on the right. The page tabs are shown at the bottom; only part of one tab is visible.

An XLANG schedule drawing has four areas of focus. The first area is the business process itself, which the business analyst can first describe without paying too much attention to the implementation aspects for the process. Figure 9.1 showed an example of a business process using Buyer1.skv schedule.

The second area of focus defines the components used to implement this process allowing developers to bind the business process to its physical implementation details. Both these areas are displayed in the Business Process page in the designer and govern how messages flow in the schedule.

The third area focuses on the definition of the data elements that flow between the messages resulting from the business process. These data elements are displayed on the Data page of the schedule drawing. Finally, the last area is related to transaction management.

This area of handling transaction failures is important. Often, you want a set of actions to occur as a cohesive transactional unit. If one or more of the actions fails, you not only need the transaction to roll back, but you also need support for describing the compensation or failure handling business logic that should be executed. This business logic is displayed on separate pages in the schedule drawing. These pages are called On Failure of <Transaction> and Compensation for <Transaction>, where the <Transaction> token is replaced by the actual name of the transaction as defined on the main Business Process page.

All the other pages in an XLANG schedule drawing refer to the main Business Process page in the schedule.