Microsoft BizTalk Server 2000: Building a Reverse Auction with BizTalk Orchestration
Summary: This article discusses the business process orchestration features of Microsoft BizTalk Server 2000. (16 printed pages)
Building e-commerce applications requires the integration of data and business processes within and across organizations. The MSDN Magazine article, BizTalk Server 2000: Architecture and Tools for Trading Partner Integration, described a set of tools and services provided by Microsoft® BizTalk™ Server 2000. These tools and services add the following data messaging capabilities to the e-commerce architect's toolbox: document specification editor, document schema mapper, data format translation service, schema transformation service, document tracking database, and security and transport services. This set of XML-based messaging services is available for early prototyping today as a BizTalk Server 2000 Technology Preview Web release from Microsoft. In this article, we describe a second, just as important, set of tools and services provided by BizTalk Server 2000 that address business process orchestration. Business process orchestration includes the visual modeling, implementation and management of distributed business processes. BizTalk Server 2000 introduces BizTalk Orchestration (BTO), which adds business process orchestration capabilities to the e-commerce architect's toolbox. BTO is based on a new application of XML called XLANG, which is a language to define the semantics of business processes and for binding process activities to software implementations. Microsoft BizTalk Server 2000 is the integrated suite of messaging tools and services described in the MSDN Magazine article combined with the business process orchestration tools and services described in this article. BizTalk Server 2000 will be available from Microsoft to download in a Web beta release this summer.
In the remainder of this article, we provide an overview of BizTalk Orchestration and drill into an example solution. With the application developer in mind, we will show how to use BizTalk Server 2000 to model a simple reverse auction. Reverse auctions are a common dynamic pricing technique characterized by a single buyer issuing a request for quote (RFQ) and accepting bids from multiple sellers.
Architectures that integrate applications and organizations must support a variety of data schemas, data formats, and application protocols. BizTalk Server 2000 messaging services provide an infrastructure to ease this burden. However, this only eases data integration challenges. Data must be integrated as part of an organization's or a value chain's e-business processes. BizTalk Orchestration (BTO) facilitates the visual modeling of processes by business analysts and the implementation of processes by developers. Additionally, a run-time engine executes the modeled business process. Finally, BTO includes tools to ease the management of processes and exceptions. All of these features leverage existing investments in Microsoft Windows® 2000, Microsoft Visual Studio®, and COM+.
Visual Process Modeling for Analysts
BizTalk Server 2000 provides a graphical environment, the BTO visual designer, for business process modeling using the professional drawing capabilities of Microsoft Visio® 2000. The environment includes three views of a modeled process. A Flowchart view is provided for business analysts. The Implementation view and the Data Flow view, discussed below, are provided for developers. In the flowchart view, the analyst models business processes by defining a series of actions. An action is a step in a sequence of execution that sends or waits to receive data. The business analyst leverages a set of built-in Visio stencil shapes to model looping, parallel execution and branching or routing. The available flowchart shapes are listed in Table 1.
|Abort||Triggers the rollback of a transaction, invoking a specified exception handling or compensation transaction schedule|
|Action||Specifies that a message is going to be sent or received through a specific implementation shape|
|Begin||Represents the start of a process|
|Decision||Branching construct to determine the next execution step based on user-defined or built-in rules|
|End||Represents the end of a branch of execution|
|Join||Joins two separate threads of execution|
|Fork||Splits a single thread of execution into two parallel threads|
|While||Looping construct to iterate through a group of actions|
|Role||Provides an abstraction to describe a set of shapes as a communicating entity that sends or receives messages|
|Transaction||Groups actions into a discrete unit of work that either completely succeeds or has no effect|
Table 1. Available flowchart shapes and their purpose
Once the business process is defined and documented, the analyst's job is complete. Figure 1 is a screen-shot of the analyst's design canvas.
Implementation Binding for Developers
In addition to the flowchart view, the visual design environment provides an implementation view and a data flow view. Given the flowchart, a Windows 2000 developer or architect uses the implementation view to bind process activities to implementation shapes such as MSMQ queues, COM+ components, Windows Script Host scripts, and, of course, BizTalk Server 2000 messaging services. Finally, the developer uses the data flow view to flow data into and out of messages that are produced and consumed by the implementation artifacts. These implementation shapes may represent self-contained business components or they may be facades for legacy applications or distributed applications. For example, a COM+ component bound to a process action may invoke a SOAP RPC method call on a remote Web service or it may use COMTI to integrate with a legacy host application. Of course, a process action may bind to BizTalk Server messaging to produce X12 or UN/EDIFACT EDI messages or instances of specifications created with the BizTalk Editor and transformed with maps created with the BizTalk Mapper. Binding to BizTalk Server 2000 messaging services is discussed in more detail in the Advanced BizTalk Orchestration Features section of this article. The completed set of flowchart, implementation, and data flow views are referred to as a BizTalk application.
It is important to understand the concepts involved with binding an implementation to a process so let's spend some time discussing bindings, ports, messages, and data flows in more detail. Each action in a BizTalk application must be bound to, or associated with, an implementation. The BTO Engine is responsible for invoking the bound implementation at the time specified in the process model. Bindings are easy to create in the BTO visual designer by simply dragging an implementation shape onto the design canvas and connecting the dots. When an implementation shape appears on the design canvas, a port is automatically created and placed in between the action shape and the implementation shape. A port is an abstraction that BTO uses to associate messages with implementations and activities. Messages represent inputs and outputs flowing to and from implementations.
For example, consider an action called CreateRFQ that is bound to a CRequestForQuote Visual Basic component that exposes the following method:
Public Function CreateRFQ() As String
The visual design tool will create messages which correspond to the in and out arguments for the CreateRFQ method. In our reverse auction scenario described below, an RFQ is defined by a BizTalk Document Specification. Messages have a property, which can point to a BizTalk specification. A port will also be created that encapsulates the input and output messages and manages the flow of data into and out of the COM+ implementation.
Once the implementation has been selected and placed on the design canvas and connectors drawn between the process actions and the port, we must tell the BTO visual designer what data elements we are interested in flowing into and out of the port. To do this we navigate to the data flow view of our business process. In this view, we see shapes that represent each of the messages we have created in our implementation view. For example, we will see messages corresponding to the CRequestForQuote output arguments. We simply draw lines between data elements in messages—the run-time engine takes care of flowing the right data at the right time into and out of our implementations through Ports. Figures 2 and 3 are screen-shots of the developer's design canvases.
Figure 3. Data Flow Design Canvas
COM+ components, MSMQ queues, WSH scripts and BizTalk messaging services are all supported in-the-box implementation bindings. Dragging each implementation onto the design canvas invokes a wizard specific to the implementation's properties. For example, a COM+ binding requires the developer to locate the registered component and select the interface and methods being bound to the port. The MSMQ binding requires the developer to specify a queue name. The BizTalk messaging services binding requires the developer to specify the BizTalk channel. Figure 4 is a screen-shot of the COM+ binding wizard. Properties on Ports, Messages, Actions and Implementations are, of course, also available outside of the wizard with a right-click of the mouse button. For extensibility, the binding architecture is open to third parties. Microsoft and other software vendors may add additional bindings such as relational databases, SOAP, or line-of-business application connectors. These third-party bindings may include implementation shapes, binding wizards, and off-the-shelf components for easy integration into modeled business processes.
Once the visual business process model is completed, the Visio design environment may be used to validate and compile the model into its XML representation. The visual design file is saved with the .skv (schedule visual) extension and the compiled BizTalk application—the XLANG—is generated with an .skx (schedule XML) extension. The BTO Engine is capable of executing the process described by this generated BizTalk application. The Engine supports processes that include branching, sequencing, concurrency, and synchronization and long-running transactions.
It is important to highlight one of the basic premises of a BizTalk application: the separation of business process and implementation. A business process may be modeled and different software components and applications may be bound to the process either statically-at design time, or dynamically-at run time. This separation between process model and implementation goes deeper than the visual design environment. This separation is a core feature of BizTalk Orchestration and truly allows business analysts and developers to quickly adapt to meet new organizational and competitive requirements.
Process Execution and Management
A BizTalk application defines a schedule for executing an implementation of a business process. The execution of the schedule is carried out by the BizTalk Orchestration Engine. The Engine is a COM+ application designed to manage a large number of concurrently executing, long-running business processes. The architecture manages long-running processes by persisting their state using Microsoft SQL Server™ 7.0 (and later versions) and COM+ components that support IPersist implementations. These persisted processes may then be re-hydrated at the appropriate time based on internal events, such as timers, or external events, such as message arrivals. Figure 5 illustrates the BTO Engine application in the Component Services MMC snap-in.
Visual Basic programmers, or other COM+ developers working in languages such as Microsoft VBScript, Microsoft Jscript®, or Microsoft Visual C++®, can instantiate a BizTalk application by calling GetObject on a URL moniker string. The following is an example of a moniker.
The moniker example above includes two parts. First, the name of the generated .skx file is provided. Second the name of the module that should be executed is given. The second part may be given by a workflow module name or by specifying an XPath query to the module's location in the .skx file. For example:
Both of these examples start the Engine and instruct it to begin executing the module named main. Note that this article is based on a pre-beta version of BizTalk Server 2000 so syntax is possible, and likely, to change by the time the beta becomes available.
In addition to the URL moniker approach to executing BizTalk applications, the Engine exposes an object model for interacting with it and with individual application instances. Besides starting and stopping applications, this object model allows third parties to build sophisticated management tools for BizTalk Server 2000. The run-time engine persists running processes as XML and stores this state in a SQL Server database. This combination of XML and a relational database with built-in XML support provides a platform for querying and managing running processes. The BizTalk Server 2000 object model coupled with access to the state of running processes, Document Tracking and Activities (DTA) database, and Windows Management Interfaces (WMI) provides a large number of opportunities for managing business processes and for building third-party tools that make this job even easier.
Now we have enough of a background to allow us to move forward with using the tools and services to actually build an application with these BizTalk Server 2000 technologies.
A popular topic in business-to-business e-commerce is dynamic pricing. A common type of dynamic pricing is a reverse auction. In a reverse auction, a buyer issues a request for quote (RFQ) to a large number of sellers. The buyer then reviews multiple bids and accepts the optimal bid from the chosen supplier. The optimal bid is usually the bid with the lowest price. This contrasts with a typical forward auction. Forward auctions consist of a seller accepting buy bids from multiple buyers. The winning bid is usually the one with the highest price. Another popular topic is the digital marketplace for matching buyers and sellers of goods and services. The marketplace is often designed to be the broker between a buyer and seller in scenarios that involve dynamic pricing. For example, a buyer might submit an RFQ to a marketplace to which he belongs. Sellers who are also members of the marketplace have a right to bid on the RFQ. The marketplace provides a mass of buyers and sellers to create a more efficient business process as well as provides value-added services such as community services, localization, and trading partner authentication. The marketplace typically charges a subscription or transaction based fee.
We will not attempt to build an entire business-to-business marketplace that implements reverse auctions in this article. However, we will implement a simplified business process that addresses the RFQ/Bid business process between a single buyer and an online marketplace. A common way to represent interactions between components in an application or organizations in a business process is with Sequence, or Object Interaction, diagrams. These diagrams can easily communicate the delineation of responsibility between entities in an interaction and the ordering of these interactions for both technical and non-technical team members. Figure 6 is a sequence diagram that represents the buyer, marketplace, and seller in a simplified RFQ/Bid process. This diagram was simplified to ensure clarity of the process. Acknowledgement and receipt messages are excluded, exception and error processing is not shown, and interactions are limited to a single buyer and single seller. Our goal for the ensuing text is to implement the buyer-side of this RFQ/Bid interaction using BizTalk Server 2000 business process orchestration features.
Figure 6. Reverse Auction Interaction Diagram
The Reverse Auction Business Process
The starting point is to visually model the business process. The business analyst does this by creating a flowchart in the Visio 2000 BTO visual designer. The flowchart should represent the business process actions taken by the buyer's purchasing department or purchasing system. Initially the buyer decides to purchase 100 widgets. An RFQ is generated that represents the details of this order including items such as required delivery dates, approved vendors, and manufacturer warranties. The RFQ is sent to a digital marketplace where it will be processed according to marketplace rules and posted for appropriate vendors to review. Vendors may post bids in response to the RFQ that are forwarded to the buyer by the marketplace. Note that the marketplace provides the implementation of buyer and seller rules such as managing approved vendor lists, authenticating credentials, and verifying credit and inventory availability. The buyer processes each bid and selects the "best" bid based on business criteria or bidding algorithms that help to ensure the best value. Once the best bid is selected, a bid acceptance is sent to the bidding vendor for transaction execution.
So let's model this business process using the BTO visual designer. We will use the term action to represent a step in the business process. The buyer requires two actions to make his buying requirements known to potential sellers: Create RFQ and Issue RFQ. Create RFQ generates an RFQ document. Issue RFQ sends the document to the marketplace. The buyer process now enters into a bid-processing loop. Each bid that is received triggers a Receive Bid action and a Process Bid action. Receive Bid consumes bids sent from the marketplace. Process Bid may be as simple as storing the bid-price, quantity, and ship date for example-in a purchasing database or it may include more complex business logic. The marketplace sends bids to the buyer until some loop exit criteria are met. These exit criteria may be something as simple as a count or a timer or a more complex business rule. For simplicity, our exit criteria will simply be the receipt of three bids. We will rely on the marketplace to ensure that each of our bids is from three separate sellers and that all sellers are buyer approved vendors. Once the loop exits, a set of business rules will be applied to select the optimal bid. Let's call this action Select Best Bid. Finally, the action Accept Bid will cause a Bid Acceptance document to be created and sent to the winning seller.
Figure 7 illustrates this business process in the BTO visual designer and includes each of the actions described above as well as a built-in While shape and canned COM+ Loop implementation to track the number of processed bids across this long running transaction. Note that a user-defined rule is provided to define the looping criteria—Counter < 3—and that a built-in continuation rule is provided by the While shape.
Figure 7. Reverse Auction Flowchart
This diagram is created in the same manner as any other Visio 2000 diagram. Create a new BizTalk application and drag shapes from the flowchart stencil onto the design canvas. Use the connector to connect actions and ensure to start and terminate the flowchart with Begin and End shapes. Once the diagram is complete, it must be saved to the file system. As noted earlier, these files have an .skv extension. We will validate and save the design after the implementation binding is complete.
The Reverse Auction Implementation
Now that the business process is defined, the developer has an opportunity to provide an implementation. Our reverse auction will make use of XML, Visual Basic and MSMQ. A more complete implementation would involve other components, such as SQL Server and third-party purchasing applications. At a minimum however, we need to provide a custom implementation for Create RFQ, Process Bid, and Select Best Bid. Issue RFQ, Receive Bid, and Accept Bid also require implementation bindings but we will leverage the built-in support for MSMQ to limit the amount of custom development needed.
The following steps are required to implement the reverse auction: define XML specifications, implement and bind Visual Basic components, create and bind MSMQ queues, bind loop counter, configure data flows, and run the application. Let's walk through each of these steps in sequence.
Define XML Specifications
First, we define the schema for the business documents we intend to exchange between buyer, seller, and marketplace. There are three such documents: Request for Quote, Bid, and Bid Acceptance. Using the BizTalk Editor, we have created specifications for each. Sample instances of each of these specifications are provided below. Recall from the MSDN Magazine article that these specifications are simply XML Data Reduced (XDR) schema with a bit of additional markup to assist the server with its translation, validation, and transformation services.
<RequestForQuote> <Product Quantity="150" Type="WidgetA"> <Warranty TimePeriod="30"/> </Product> <Product Quantity="225" Type="WidgetB"> <Warranty TimePeriod="120"/> </Product> </RequestForQuote> <Bid> <Product Quantity="150" Type="WidgetA" TotalCost="1345.65"> <Availability PromiseDate="2000-09-09" PromiseQty="101"/> </Product> <Bidder BidderOrgID="TheBidder"/> </Bid> <BidAcceptance> <Product Quantity="150" Type="WidgetA" TotalCost="1345.65"> <Availability PromiseDate="2000-09-09" PromiseQty="101"/> </Product> <Bidder BidderOrgID="TheBidder"/> </BidAcceptance>
Implement and Bind Visual Basic Components
Second, we identify and build components required to implement Create RFQ, Receive Bid and Accept Bid. We will define a class for RFQs called CRequestForQuote and a class for Bids called CBid. Although for production projects, it is a best practice to define interfaces prior to writing code, our sample application is simple enough that we will just use the default interface created by Visual Basic Public functions and subroutines. CRequestForQuote exposes the public method CreateRFQ(). CreateRFQ() takes no arguments and generates an instance of the RequestForQuoteSpec. CBid exposes the public methods ProcessBid() and SelectBestBid(). ProcessBid() accepts an instance of BidSpec.xml for application processing. SelectBestBid() takes no arguments and returns an instance of BidSpec.xml that represents the winning vendor bid. Stub implementations for each of these methods shown below.
After the Visual Basic components are registered, we can drag a COM+ implementation shape from the implementation stencil onto the design canvas. This initiates a Wizard for pointing the shape to the appropriate registered components and allows us to select which interfaces and methods we would like the BTO Engine to invoke. A port is created and messages are created for the input and output arguments derived from the input and output arguments of the COM+ component. We use the connector to associate the flowchart action with the port and to associate the port with the implementation shape. Figure 2, shown earlier, illustrates the COM+ implementation binding process. There is one implementation step remaining to complete our Visual Basic binding. The data flow into and out of the component must be configured. We will configure all data flows after we complete our implementation bindings, as shown below.
CRequestForQuote ----------------- 'CreateRFQ() interacts with a hypothetical line-of-business application 'to create an XML RFQ document instance. The RFQ is returned. Public Function CreateRFQ() As String CreateRFQ = 'get the document End Function CBid ---- 'ProcessBid() is given an instance of an XML Bid and submits it to an 'auction application for processing. Public Sub ProcessBid(ByVal xmlstrBid As String) 'send Bid to LOB Return End Sub 'SelectBestBid() asks the auction system for the best bid and 'returns it as an XML document instance. Public Function SelectBestBid() As String SelectBestBid = 'get the document End Function
Create and Bind MSMQ Queues
Third, we identify implementation required for the Issue RFQ, Receive Bid, and Accept Bid actions. For each of these, we will leverage the seamless support for MSMQ built into BizTalk Server 2000. Issue RFQ will be bound to a queue called RFQOut. Receive Bid will be bound to a queue called BidIn. Lastly, Accept Bid will be bound to a queue called BidAcceptanceOut. BizTalk Server 2000 will do all the work required to place messages on these queues and read messages off the queue. The BTO Engine will flow the specified messages into the queue and from the queue into the bound Visual Basic components. No coding required. For this sample application, we use private queues running on the local machine. This allows the sample to run on a single stand-alone Windows 2000 Advanced Server. The queues are named the following:
.\private$\BidIn .\private$\RFQOut .\private$\BidAcceptanceOut
It is important to specify each BTO queue to be transactional. For simplicity, this example binds directly to MSMQ queues. In a real scenario involving integration with an online exchange or trading partners, our binding is likely to require the data format translation and data schema transformation services of BizTalk messaging services. It may also make sense to leverage the secure transport features of BizTalk messaging. For example, business documents may be encrypted and digitally signed using S/MIME and then posted over a secure HTTPS channel. In this case, we would simply replace our MSMQ binding with a built-in BizTalk messaging services binding shape and configure the Channels and Ports in the BizTalk Management Desk. The BTO Engine application may be referenced directly from the Channel and Port Configuration Wizards. The integration is seamless. Nevertheless, for the sake of brevity and clarity we bind directly to MSMQ queues in this sample application.
After our queues are created, our binding process is very similar to what was required to bind the Visual Basic components. We simply drag a MSMQ implementation shape from the implementation stencil onto the design canvas. This initiates a wizard for pointing the shape to the appropriate queue. A port is created and a message is created for the data being placed on or read from the queue. We use the connector to associate the flowchart action with the port and to associate the port with the implementation shape. Figure 8 illustrates the completed MSMQ and COM+ implementation binding process.
Bind Loop Counter
Fourth, we must provide an implementation binding for the loop counter. For this, we use a canned, or in-the-box, LoopControl component that exposes Initialize() and Increment() methods. In the prerelease version tested for this article, the binding process was identical to the process used for the Visual Basic components. It is likely that this step will be simplified in the released version of BizTalk Server 2000. Certain activities such as looping, counters, and timers are commonplace in business processes and may be provided as out-of-the-box artifacts for inclusion in any design.
Configure Data Flow
Once this binding is complete, there is one item left for the developer. Data flow must be configured on the data flow view, or in Visio parlance, the data flow sheet. The best way to describe the flow is with an illustration. Figure 9 is a screenshot of the completed data flow for the reverse auction sample application. There are six flow steps.
- CreateRFQ generates a RFQ document instance that flows into the RFQMessage.
- RFQMessage is placed on the outbound RFQOut queue.
- Bids are received on the inbound BidIn queue and flow into the BidMessage.
- The BidMessage flows into the ProcessBid input arguments.
- SelectBestBid generates a Bid instance that flows into the BidAcceptance Message.
- The BidAcceptanceMessage is placed on the outbound BidAcceptanceOut queue.
Note that we take a shortcut in this sample application. We magically turn the best Bid into a BidAcceptance. In a full implementation, we would use BizTalk messaging schema transformation services to perform this magic for us and insert the appropriate data fields from a Bid into the appropriate fields in a BidAcceptance. We may even leverage BizTalk Functoids to perform database looks up or other custom processing during the mapping process.
Running the Reverse Auction
Now that the activity diagram, implementation binding, and data flows are complete, we use the Validate option of the BTO visual designer menu to validate the workflow and locate any errors. After all errors have been fixed, we can generate and save the application design file. The file, generated with an .skx extension (for schedule XML), is a well-formed XML document that describes the business process to the BTO Engine. Figure 10 is the completed BizTalk application.
A simple test harness was built using Windows Scripting Files (also known as Scriptlets). This HTML/JScript application simply creates and executes an instance of the reverse auction application and provides a button to place Bids on the inbound queue. Monitor the outbound BidAcceptance queue to determine when the Bid Acceptance is sent indicating completion. Simply run the application, send three bids and the BTO Engine does the rest. To gain a little more visibility into inner workings of the run time, open the MSMQ Explorer and monitor the arrival and departure of messages. Turn on queue journaling for more detail. Finally, COM+ Spy in the Platform SDK allows you to monitor, at the Action and Port level, precisely what the BTO Engine is doing by trapping BizTalk Events. Figure 11 is a screenshot of the test harness and Figure 12 shows the reverse auction queues in the MSMQ MMC snap-In.
Figure 11. Reverse Auction Test Harness
Figure 12. Reverse Auction Queues
The BizTalk specifications, sample instances, Visual Basic implementation stubs, BizTalk visual design (.skv), XML (.skx) files, and the wsf/htm test harness used in this article will be converted to work with the Web released beta BizTalk Server 2000 and made available for download from MSDN.
The reverse auction sample application described in this article only touches on the features provided by BizTalk Orchestration. The buyer's business process includes a single path of execution with a simple while-loop and a counter. A real business process is much more complicated. BizTalk Server 2000 provide features such as roles, dynamic ports, transactions, and BizTalk channel binding that allow these complex processes to be modeled and implemented using the tools and services employed in this article.
Most business processes involve multiple persons, computer systems, applications, or organizations interacting in complex ways. Roles are a BTO visual designer feature that is available to support this type of application. A role is an entity that sends or receives messages and may be a collection of multiple roles. A business process can easily be broken into sub-processes and associated with a role. The roles can then communicate with each other to achieve the desired result. A simple example of this would be to extend our reverse auction sample application to include the seller business process in addition to the buyer process we have already modeled. We could then create a Buyer and a Seller role that communicate through a Marketplace role.
While roles help the modeler and developer modularize business process development, features such as sequential, concurrent, and conditional execution of actions allow the modeling of complex processes. The Fork and Join shapes provide a mechanism to model concurrency. The Decision and While shapes provide a mechanism to model conditional execution. Rules allow the business analyst or developer to query run-time information such as message values and to route the process' execution accordingly. Of course, each of these graphical shapes is translated into a description of the process and binding and the run-time engine manages the execution of these advanced process constructs.
Another characteristic of most business processes is their dynamic nature. The separation of process from implementation that BizTalk Server 2000 provides goes a long way towards supporting business processes that frequently change. However, what if the business process changes based on run-time characteristics? For example, our reverse auction buyer may wish to send an RFQ for direct goods directly to a small set of suppliers but send an RFQ for non-direct goods such as office supplies to a digital marketplace for ad hoc bidding. Dynamic ports are provided for this type of challenge. A process may be modeled that allows an implementation to be selected at run time. In our example, we might simply bind to a different queue based on the type of good being requested in the RFQ.
The Transaction flowchart shape was introduced earlier in the article. This shape is important because it represents an important BTO feature: support for both short-lived Microsoft Distributed Transaction Coordinator style transactions and long-running transactions. Long-running transactions are groups of short-lived transactions that must be treated together as discrete units of work. An important requirement of transaction design is the ability to rollback previously completed work when an error occurs. In a long-running transaction that is distributed across a wide-area network such as the Internet, a traditional two-phase commit transaction is undesirable but we would still like to commit and rollback the transaction as necessary. In these cases, the architect must provide the application infrastructure with details on how to undo work items in the case of failure. The BTO visual designer allows an architect to specify a Catch process or a Compensating process that will be invoked by the BTO Engine to catch error conditions or to provide a compensating transaction to undo work already completed.
The last and possibly most important feature of BizTalk Server 2000 is the seamless integration between the business process orchestration capabilities of BTO and the data processing capabilities of BizTalk messaging services. Note that some of the terminology between technology preview and beta has changed. Loosely speaking, pipelines are deprecated and channels and ports are introduced in the core-messaging engine. This allows trading partner agreements to be configured in the BizTalk Management Desk as channels and ports that can be bound directly to actions in a business process. Features such as SOAP Enveloping via the BizTalk Framework, Distribution Lists, Specifications, Maps, Transport, and Security Settings are all available directly from a business process. The Binding Wizard for BizTalk Messaging simply allows the developer to provide the name of a channel.
In summary, this article discussed the business process orchestration features of BizTalk Server 2000. These features, called BizTalk Orchestration, coupled with the core BizTalk Server 2000 data messaging services discussed in the MSDN Magazine article comprise a sophisticated set of Windows 2000 XML based tools and services for integrating applications within and across businesses. Many of the data messaging features are available today for prototyping in the Technology Preview release, while the upcoming Web release of BizTalk Server 2000 Beta will provide an opportunity to begin piloting next generation e-commerce architectures. Visit the BizTalk Server Web site to keep up to date.
Bob Laskey is an e-commerce architect in Microsoft's dot-com consulting practice based in Austin, TX. He can be reached at email@example.com.
James Parker is an e-commerce architect in Microsoft's Industry Solutions Group based in Austin, TX. He can be reached at firstname.lastname@example.org.