3. State Repository
Microsoft’s
BizTalk Server manages orchestration state in much the same way as WF,
except that state management is not extensible or configurable. BizTalk
Server always stores the state of an orchestration in a SQL Server
database to ensure durable and scalable storage (Figure 1). This results in a natural application of State Repository , a pattern that is used for a range of state deferral options.
The
BizTalk runtime engine dehydrates idle orchestration instances whenever
possible to conserve server resources. The orchestration engine detects
when the orchestration becomes idle and waits for a certain period of
time, then persists the orchestration into the SQL Server database and
frees up any server resources associated with that instance of the
fulfillment process.
BizTalk rehydrates an
orchestration when it receives a message for the orchestration instance
giving it an indication that it’s time to resume processing. For this to
work, BizTalk needs to be able to identify data in a message that can
uniquely identify the orchestration instance to rehydrate. For this
purpose, it is common to use correlation types.
It is expected that,
while hydrated, an orchestration remains stateful until its execution is
completed. The services composed by the orchestration logic, on the
other hand, are preferably designed to defer state via State Repository, or other patterns, such as Stateful Services, Partial State Deferral, or even State Messaging.
Compensating Service Transaction
BizTalk supports compensation-style transactions in compliance with the application of the Compensating Service Transaction
pattern. Compensation logic generally needs to be invoked when an
orchestration needs to clean up work it performed successfully before
another part of the orchestration failed.
You configure an
orchestration for compensation by setting the Transaction Type property
of a Scope to Long Running as illustrated in Figure 2.
BizTalk will
automatically invoke the compensation handler (and nested handlers) as
needed to invoke compensating service operations when an error occurs
during the execution of the scope.
Just like a catch
block behaves as an exception handler in a C# routine, the compensation
handler is simply extra logic that is explicitly invoked under certain
conditions.
Figure 3 shows how each scope can define a separate compensation handler.
The compensation algorithm displayed in Figure 3 creates two messages to cancel orders in two other services. Note that when applying Compensating Service Transaction,
there is no rollback of changes. The most common approach is to equip
service contracts with compensating capabilities that correspond to the
original capabilities that were executed up until that point (for
example, a CreateOrder operation may have a corresponding CancelOrder
operation).
Note
BizTalk Server also supports the application of Atomic Service Transaction with a two-phase commit protocol. This allows for the ACID transactions
to occur within orchestrations and within the scope of broader
compensation transactions, if necessary.
For longer-running orchestrations, it is more common to manage exceptions using Compensating Service Transaction because the use of Atomic Service Transaction
requires that resources be locked and the original (pre-transaction)
state be preserved in order to enable subsequent rollback of changes to
the original state.
Prior to the integration of
WCF, BizTalk server did not support the WS-AtomicTransaction industry
standard. Therefore, BizTalk 2006 and earlier versions could only
coordinate transactions across resources where appropriate resource
managers are available.
