Development, Runtime, and Deployment Considerations

This section provides general insights into designing, running, and deploying BizTalk Orchestrations. We look at aspects of robustness, scalability, and performance.

As a general guideline, to design a good BizTalk Orchestration Schedule, you must be able to factor your business process into the operations supported by BizTalk. By understanding the transaction support and error-handling characteristics of XLANG schedules, you can partition your business process into logical units that maintain the consistency and integrity of your business operations. You may also want to entertain the thought of modifying or re-engineering your business processes to truly automate them.

The following sections describe some things to keep in mind.

Robustness

You may recall that the messages in an XLANG schedule can carry COM interface handles around. Be careful when doing this because of what the XLANG engine could do when it dehydrates and rehydrates a schedule.

When a schedule is dehydrated, the XLANG engine calls the component to persist its state. When the schedule is later rehydrated, the engine constructs a new component and asks it to restore its state from the earlier persisted state. Now, if the component is implemented correctly, and the state is in fact restored correctly, and all is fine. The messages that contained the original COM interface are updated to contain the new interface; however, if another COM component had received this interface, it is no longer valid. This could occur if you passed the interface to the component as part of a message field. It is desirable that all your components support persistence or not hold any state.

Performance and Scalability

Here are some pointers to optimize performance of your schedules:

• Run the COM objects on the same server as the BizTalk Orchestration Persistence database. This eliminates the network latency to access the persisted state of the objects when the schedule is rehydrated. This means that, to achieve scalability, you should spread out related schedules and their objects on different servers each with its own persistence databases.

• Manage the dehydration of your schedules. Dehydrated schedules do not consume system resources other than the relatively inexpensive space in the database.

• Consider the trade-off of running COM+ packages in-process versus out-of-process. In-process deployment is faster; however, a failure in one application causes all applications in the failed process to fail.

• To support transactions, the XLANG Scheduler Engine checkpoints the state of the running schedule at the beginning and end of a transaction. This is an expensive operation. Batching work in a single transaction can alleviate this load; however, it might make error handling more complex.

• An XLANG schedule cannot dehydrate in the middle of an MSDTC transaction; however, these transactions are quick. Yet, try to lump multiple quick actions in a single short-lived transaction to conserve system resources.

• Try to decouple communicating applications by using asynchronous messaging. This enables a higher throughput at the expense of some latency. This is true in particular for long-running transactions and long-running business processes.

• Design COM components so that they finish their work quickly. If they must be time consuming, consider designing them so that they return synchronous calls quickly, but later the results of their work can be returned asynchronously.

If your XLANG schedules do not dehydrate, explore some of the following reasons:

• Pending actions, such as waiting to receive a message, have an associated acceptable latency. If this is greater than 180 seconds, then the schedule dehydrates immediately, barring other reasons not to.

• The schedule is not quiescent; not all actions in the schedule are in the same state. Unless forcibly dehydrated, a schedule dehydrates only when all actions that are ready to run must wait for an event—for example, a message to arrive.

• There are pending short-lived transactions.

• The state of a component bound to a port cannot be persisted. Such a port is called a live port. Although the state will be lost if the system crashes or there are other failures, the engine holds on to the port in the hope that the schedule will finish successfully.