Chapter 11. XLANG Orchestration Engine
by Dilip Hardas
In This Chapter
The XLANG Orchestration Engine controls the activation, execution, dehydration, and rehydration of running XLANG schedule instances. In Chapter 9, “Introducing BizTalk Orchestration,” and Chapter 10, “Using the BizTalk Orchestration Designer,” you learned how to create and compile BizTalk Orchestration schedules into an XML grammar named XLANG. In this chapter, you learn how the XLANG schedule created by the designer is processed.
When you install BizTalk Server 2002, several COM+ applications are created and configured, including one named the XLANG Scheduler. For a primer on COM+, see the sidebar. The XLANG Scheduler COM+ application hosts the default instance of the XLANG Scheduler Engine. To instantiate an instance of an XLANG schedule, you pass the moniker of an XLANG schedule to the XLANG Scheduler Engine. The engine instantiates the schedule instance and then begins to execute it. During the execution of the schedule, the engine may need to dehydrate or save the current state of the schedule. This occurs when the XLANG Scheduler Engine expects to wait for 3 or more minutes to receive a message. The engine, utilizing COM+ services, provides all the runtime services needed to execute the compiled XLANG schedule.
COM+ Primer for BizTalk OrchestrationCOM+ is an evolution of COM—an acronym that stands for Component Object Model. COM+ provides component services such as security, transaction management, process isolation, thread allocation, concurrency, object pooling, and others to applications that you develop and deploy on the Windows 2000 system. A COM+ application is a group of COM components that share a common context (such as security and transaction) within COM+. This application is the primary unit of administration in COM+. For BizTalk Orchestration, the COM+ applications used to host XLANG schedules are server applications, as opposed to library applications. In a server application, components run in a dedicated system process provided by COM+, whereas in a library application, the components run in the caller's process. Access to server applications, and the contained components and methods, is controlled by COM+ role-based security. The application process itself is run under a designated Windows logon identity. It is customary for this identity to be Interactive User during development, although this setting is unacceptable in a production situation. Components in a COM+ application are called configured components, and these components can take advantage of COM+ services. With configured components, it is easier to build robust, scalable, and secure applications. The XLANG Scheduler Engine is set up as one or more COM+ applications that can host running schedule instances. These applications can also contain configured components used by the running schedules. The components and schedules can be easily secured using COM+ security mechanisms. Short-lived XLANG transactions are integrated with COM+ transactions. COM+ events are used by tools that monitor schedule execution. |
This chapter discusses the runtime behavior, programming model, and monitoring tools for the XLANG Orchestration Engine.
Specifically, you will learn:
How XLANG schedules are run on the system
What programmatic interfaces are supported to access these running schedules
How to monitor these schedules in real-time and generate historical traces for troubleshooting
How this information affects your design
You will recall from Chapter 9 that the XLANG Orchestration Engine implements a moniker class of the type sked. The chapter also described the moniker syntax supported by this moniker class and listed the corresponding objects provided by the class implementation. Later in this chapter, we will review each of these objects along with their properties and methods. Figure 11.1 is a pictorial summary of the runtime object model and the associated moniker syntax.
Figure 11.1. Objects exposed by XLANG Orchestration Engine.
Figure 11.1 shows interfaces defined by SkedCore.dll (type library is called the XLANG Scheduler Runtime Type Library) and objects and collections implemented by SkedsMgr.dll (type library is called the XLANG Scheduler – System Manager). The figure also shows the key interfaces exposed by those objects. When you use these objects or interfaces in your programs, you can reference these type libraries.
Figure 11.1 shows the System Manager as the root of an object hierarchy. The COM class for the System Manager is called SYSMGRLib.SysMgr. The System Manager class is installed in the COM+ application named XLANG Scheduler. This is also the default host for running schedule instances and contains the default instance of the XLANG Scheduler Engine.
There is a single instance of the System Manager root object on a server. This instance exposes a collection of group managers on that server. Each group manager represents a COM+ application on the server that can host the XLANG Scheduler Engine and run instances of XLANG schedules. Not all COM+ applications are enabled to run XLANG schedule instances and therefore are not group managers.
Each group manager instance exposes a collection of currently running schedule instances, and each instance in turn exposes port proxy objects for its COM bound ports. Although a group manager runs a single instance of the engine, it can run multiple instances of an XLANG schedule. Also, two instances of the same XLANG schedule can run in different group managers. Each running schedule is represented as a distinct object in the collection exposed by a group manager. Moreover, the engine provides access to ports bound to COM components in the schedule instance by exposing proxies for these ports. These proxies may be used by other applications wanting to communicate with the running schedule instance.
The System Manager class provides administrative access to all group managers on the server—that is, to all COM+ processes that can host the running XLANG schedule instances. Figure 11.1 also shows the composition of the sked moniker and relates it to the object hierarchy.
This chapter discusses all of this. First, you learn how the XLANG Scheduler Engine hosts schedules—that is, how schedule instances are managed, persisted, dehydrated, or rehydrated. Then, later in the chapter, you look at the details of objects exposed and the events generated by the engine and, finally, the tools used to monitor these events. The chapter also contains example code to use the runtime APIs described. Visual Basic 6.0 is used for the examples.