Orchestration Hosting Infrastructure
Let's look at the hosting infrastructure for running the XLANG schedules. This is provided by COM+ Services and by SQL Server 2000 database server.
Recall that the XLANG schedules embody long-running business processes; hence, running schedules must survive system restarts. Also, to support scalability, BizTalk Orchestration Services may dehydrate running XLANG schedules. These are schedules that have become quiescent and are now waiting for some event to occur before they can continue running. SQL Server 2000 provides the persistence database for saving the state of running schedules. COM+ application services provide the processes and the environment to run XLANG schedules. The following sections discuss each of these two areas.
COM+ Services
COM+ provides a number of services to components installed in a COM+ application. An XLANG schedule instance runs in the context of a COM+ application and takes advantage of the deployment and security configuration options as well as process isolation features of COM+. COM components referenced by an instance of a schedule leverage the object pooling, transaction management, just-in-time activation, and concurrency support services provided by COM+.
When BizTalk server is installed, a new XLANG tab is added to the properties page of all COM+ server applications (see Figure 11.2). COM+ applications that are activated as a library do not have this tab. The XLANG tab is used to configure the execution of the XLANG Scheduler Engine within that COM+ application. However, by default, the engine is enabled to run only within the XLANG Scheduler COM+ application, which is created when BizTalk is installed.
Figure 11.2. XLANG Scheduler Properties.
You can create new COM+ applications and enable them to host the XLANG Scheduler Engine and run schedule instances. Schedule instances running in two separate COM+ applications are isolated from each other because they run in separate processes. Also, the two COM+ applications can be secured differently.
When you develop a business process in an XLANG schedule, consider the deployment and security issues of running the schedule. These considerations will determine what COM+ applications you create, the configuration for these applications, your choice of databases, and security options. You may choose, for example, to dedicate a COM+ application to run schedules associated with a trading partner. This approach permits the business processes to be secured differently, based on the trading partner relationship, and to isolate them from each other, permitting you to, for example, shut down one process without affecting the other. Let's look at the configuration options in detail.
The default application to host XLANG schedules, as set up by the BizTalk Orchestration Services installation script, is a server application called XLANG Scheduler. By default, this server application uses the Interactive User identity to run the schedules (this identity is defined in the property pages of the COM+ application). The XLANG Scheduler application hosts the System Manager component that oversees all schedule activations on the server. Figure 11.2 shows the XLANG property page for the XLANG Scheduler COM+ application along with tabs for other pages.
The check box on the top left in Figure 11.2 designates this application as an XLANG schedule host. It is grayed because changes to this application currently are disabled. The buttons and configuration settings shown on the XLANG tab of this property page are referenced throughout this chapter. Note the other tabs shown in Figure 11.2. Each tab serves a purpose; the default settings in tabs on Security and Identity usually need changes.
Access to the XLANG Scheduler application is controlled by COM+ role-based security. Hence, the object model described previously, exposed by the System Manager, is selectively available depending on the identity of the user or process accessing it.
The security roles defined for the XLANG Scheduler application are as follows:
XLANG Schedule Creator— Allows a user to create XLANG schedule instances. By default, the Windows 2000 built-in group of Everyone is added to this role.
XLANG Schedule User— Allows a user to interact with an XLANG schedule instance. By default, the Windows 2000 built-in group of Everyone is added to this role.
XLANG Schedule Administrator— Allows a user to perform administrative tasks. By default, the Windows 2000 built-in group of Administrators is added to this role. The administrative tasks are related to tasks on the XLANG tab of the COM+ application property page, shown in Figure 11.2. They are
Declaring an application to be a host for XLANG schedules
Setting the persistence database configuration
Shutting down XLANG applications
Suspending, resuming, or terminating XLANG schedule instances
XLANG Scheduler Application— Allows the XLANG Scheduler to interact with applications running with an identity included in this role. By default, the Windows 2000 built-in group of Everyone is added to this role. For example, another COM+ application running with an identity not in this role cannot use restricted features of the XLANG scheduler object model.
Figure 11.3 shows the Component Services administration console and the COM+ applications therein.
Figure 11.3. XLANG Group managers and security roles.
Figure 11.3 shows COM+ applications in the left pane and their Status view in the right pane. Two of these applications, XLANG Scheduler and XLANG Two, are group managers and are XLANG hosts. The left pane also shows the security roles for the XLANG Scheduler application. The installed component shown is SysMgr from the SkedsMgr.dll. The roles for XLANG Scheduler application are also shown. Note that roles are defined only for the default XLANG schedule host application, which also contains the SysMgr. The right pane shows three applications running. Besides the System Application, the other two are group managers. Note the process ID for the running group managers—this will show up in event traces discussed later in this chapter.
The security roles are used in many ways:
Any user that you want to allow to kick start a schedule should be added to the XLANG Schedule Creator role. If an application starts a schedule instance, then the identity used by the application process should be part of this role.
You can control who can interact with a running XLANG schedule instance by specifying users in the role XLANG Schedule User. Note that this level of control is in addition to other mechanisms available to you—for example, checking the sender's identity within the schedule or specifying access control on messaging queues or role-based security on COM+ configured components.
You can restrict which users or application processes can access the XLANG Scheduler by controlling the membership of the XLANG Scheduler Application role.
If, at runtime, an access fails because of a role-based security violation, then an event log entry is generated in the system event log.
You have the choice of configuring multiple COM+ applications to host XLANG schedules. There are both pros and cons of running schedules in the same COM+ application. The advantages of running schedules in the same COM+ application or group manager are as follows:
An interaction between the schedules does not incur out-of-process call overhead, hence resulting in better performance
All schedules in that group manager can be selectively shut down, without affecting schedules in other applications
All the schedules in the group manager have the same security profile. The schedules run under the same user identity
The schedules share configured COM+ components and the likelihood of instance reuse is higher for properly implemented components
There are disadvantages, on the other hand, of running schedules in the same group manager. The advantages of running schedules in different COM+ applications or group managers are as follows:
The schedules are part of different business processes and running them in separate processes isolates them from each other's failures
A schedule has specific security needs, possibly because it interacts with outside organizations or other legacy applications with special configuration requirements Running it in a separate group manager allows customization of the security configuration.
The business processes embodied in the schedule are still under development and the production applications must be isolated from the running and failures of these schedules Running the schedules under development in different group managers allows you to shut down schedules under development without affecting the production schedules.
You can isolate the persistence database for schedules that run in separate group managers. You may want to do this possibly due to a business requirement for segregating the databases or servers.
You want to make it easier to migrate the schedules to run on a different server some time in the future. At that point, you can create the group manager on the new server and point your references to this new server.
To create a group manager, you must first create a COM+ server application using the COM+ Application Install Wizard. To start this wizard, first start Component Services administration console, see Figure 11.3. Right-click on the COM+ Applications tree node and use the menu to create a new application. The wizard starts with the welcome page. The next page of the wizard is Install or Create a New Application. Choose to Create an Empty Application by clicking the button labeled as such. The wizard asks you to name the application. By default, a server application is created, which is what you want. On the next page of the wizard, you are asked to choose an application identity. By default, the identity is Interactive User, which is adequate for development purposes. You can change this identity later on the property page of a COM+ application. Clicking Next concludes the process of creating a COM+ application.
The COM+ application created is not yet a group manager; it cannot host the XLANG Scheduler Engine or run instances of XLANG schedules. To do this, you must go to the XLANG tab (refer to Figure 11.2) of the property page of the newly created COM+ application and check the box labeled This Application Is a Host to XLANG Schedule Instances. If, at this point, you decide to close the property pages for this COM+ application, then you will be prompted as shown in Figure 11.4.
Figure 11.4. Creating the COM+ application for a group manager called TestApp.
The prompt reminds you that you must specify a persistence database for the engine to use before the COM+ application can become a group manager. We look at the persistence database in the next section and at the steps necessary to create and configure such a database.
Note
Any COM+ application that you create and designate as a host for an XLANG schedule must have at least one COM+ configured component installed.
This component may be used by an application or by a running schedule. However, if there is no such component, then you must define a dummy component so that the COM+ application can be started and be an XLANG host.
Note
It's a good idea to change the default identity for the XLANG Scheduler application to be a service account.
A service account is like any other user account with specific rights. Such an account must have the right to “Act as part of the operating system” and “Log on as a service”. The default setting of Interactive User works fine for developers.
Not changing the identity in production or test systems could result in applications either not working, or working nondeterministically depending on who is currently the interactive user on the server machine(s). Failure to change the identity could also provide unintended privileged access if a system admini-strator happens to be logged on to the server.
It is recommended that you assign a specific user identity for each COM+ application instead of using the default identity of Interactive User. The identity you select is available to recipients of all messages posted by a schedule running in this group manager.
The name of the hosting COM+ application is used as the name of the group manager portion of the schedule moniker. Hence, by using the name of the COM+ application, in the moniker, you can designate which process should host the schedule instance. Here is an example of a valid moniker:
sked://MyMachine!XLANG Two/C:TempExampleSchedule.skx
This moniker refers to the group manager XLANG Two on the server called MyMachine. Chapter 10 covered the composition of sked monikers. You will also see additional moniker forms and moniker usage in subsequent sections.
Caution
Group manager names are case-sensitive and can contain spaces. Pay attention to moniker strings in this regard.
Persistence Databases
Another COM+ application that is installed by default is the XLANG Scheduler Persistence Helper, which provides database persistence services to running XLANG schedules. This is a Library application and, therefore, does not run in its own process. You can see this in the Component Services administration tool (refer to Figure 11.3). The persistence database stores the structure of the XLANG schedules being run, the dynamic state to track the progress of schedules being run, and a checkpoint state of all messages sent or received prior to dehydrating a schedule.
A persistence database is created when the default XLANG Scheduler application is created. This database is called XLANG; however, you could specify another name for a new database or bind to an existing database when BizTalk Orchestration Services are installed.
When you define a new application to host XLANG schedule instances, you must associate a database with this new application. The database you associate will be used to save the running XLANG schedule state when the schedule is dehydrated. You can choose to associate the default database or an existing database, or create a new database.
The database used by an XLANG hosting application is specified on the XLANG tab of the COM+ application's properties dialog box. The steps to associate a database are as follows:
1. |
Create the database using the SQL Server Enterprise Manager administration tool, unless you want to reuse an existing database. |
2. |
Grant access rights to this database for the user identity that will be used to run the XLANG host application. You will need to grant permission to create tables and procedures in this database. |
3. |
Create a data source name (DSN) to this database. Note that, for the default persistence database used by XLANG Scheduler, the BizTalk Orchestration Services always uses the Windows user identity for authentication instead of SQL Server authentication. Also, note that the name of the DSN must be identical to the name of the XLANG hosting application. Do not forget to check the Use File DSN check box, if in fact you use a file DSN. File DSNs are accessible from multiple servers in a group or a cluster using UNC path names. (UNC stands for universal naming convention, which defines a machine independent syntax for locating files). |
4. |
Initialize the database, unless you are using an existing database. However, you can initialize an existing database, if in fact that is what you want to do. You initialize the database using the button on the XLANG tab of the group manager's property pages. |
Note
Pay particular attention to the restrictions stated in step 3 on defining persistence database DSNs. Failing to properly configure the DSN and the persistence database will cause schedule persistence and dehydration to also fail.
To create a group manager, you must create a COM+ application and then enable it to host XLANG schedule instances. As part of enabling it to host running schedules, you must create a persistence database. This is what Figure 11.4 showed.
If you click the Create DSN button, you are reminded of items shown in Figure 11.5.
Figure 11.5. Creating a persistence database for a group manager called TestApp.
Clicking OK starts the Create New Data Source Wizard. Here you can create a file, user or system DSN. Select a SQL Server 2000 database server to host the database, and you should have created the database beforehand as described in the steps earlier. When the wizard for creating a DSN finishes, the wizard to configure the DSN is automatically started. Here you specify the database server, login information, and database name to use. Note that you could alternatively create and configure the DSN independently using standard administrative tools such as the ODBC Data Source Administrator. If you do this, you should update the DSN information by clicking the Configure DSN button. Remember to check the Use File DSN check box if in fact you use a file DSN.
At this point, you are ready to initialize the database for use by the XLANG Scheduler Engine. To do this, click the Initialize Tables button. Figure 11.6 shows the reminder when you do this.
Figure 11.6. Initializing the persistence database for TestApp.
Click Yes to initialize the database. This adds the tables and stored procedures to the database as needed by the engine. Remember to add at least one COM component to the group manager as noted in the previous section.
At this point, you are good to go. You can run XLANG schedule instances in the XLANG hosting COM+ application you just configured, and the schedules will dehydrate to the associated database when they are quiescent.
If you look at the XLANG tab on the properties page of the hosting application, you will see a button designated for Controlled Shutdown. If it is the default application that you are looking at, XLANG Scheduler, then the button can shut down all XLANG instances on the server in a controlled manner. On a group manager that you create the button can be used to shut down all instances only in the current hosting application or group manager.
A controlled shutdown allows the XLANG Scheduler Engine to gracefully save the state of the schedule before stopping the application. You can later rehydrate all dehydrated XLANG schedules in all group managers by clicking the Restart Dehydrated XLANG Applications button on the XLANG properties page of the XLANG Scheduler application (refer to Figure 11.2). It is not a good idea to use the Component Services administration console to shut down a group manager because the state is not properly persisted when this brute force approach is taken. For example, if a schedule using per-instance MSMQ queues is shut down by force, you may get dangling MSMQ queues created by the engine.
Just as there were considerations for choosing to run schedules in the same group manager versus creating new group managers, there are reasons to choose the XLANG persistence databases used with each group manager. The size of the XLANG persistence database grows as schedules dehydrate and rehydrate. Different persistence databases can be secured separately. The network latency to the persistence database affects the speed of dehydration and rehydration. These observations suggest the following:
Use different databases to isolate schedules used in different business processes. This way the business processes will not contend for disk resources, and they can be securely isolated using separate logon identities.
Share a SQL Server to host all databases used for XLANG persistence. Having separate servers just adds unnecessary complexity. The chosen server should have low latency LAN connectivity to the other BTS servers hosting XLANG schedules. The server should also have fast disks and controllers, possibly with striping and mirroring built in.
Use separate databases for different versions of schedules. For example, schedules being developed for a business process should have a separate database from the database used for the schedules for the production version of the business process.
The next section explores the object model exposed by the XLANG Scheduler Engine. The description covers all the properties and methods of each of the exposed objects. The format presents the signature immediately after the heading naming the property or method. This is followed by the description and usage. This format should make it easy to locate information quickly.