Managing the Programming Model Extensions

The programming model extensions introduce functions that need to be administered. The PME installation image also comes with an extension to the admin console and underlying management facilities. When you install PME you will automatically see these extensions show up in your admin console – either in the standalone server management facility, or in the deployment manager if you are managing a network deployment cell. You have to be sure to install the PME image on the computer that has your deployment manager in the latter case.

The differences introduced by the PME admin extensions show up in five principle ways:

• Additional configuration topics in the application server definition

• Additional configuration topics in the application definition

• Additional resource types (representing the services introduced by PME)

• Additional options on previous configuration topics

• Additional sample applications

Configuring the Application Server Extensions

When you first open the Application Server configuration page it will look the same as usual.

However, after scrolling down, you will notice several new configuration subjects.

• Work Area Service – can be used to enable or disable the service in this server instance, and set the maximum send and receive message lengths that will be allowed by the service at this server.

• Internationalization Service – enables or disables the Internationalization service at this server instance.

• Application Profiling Service – enables or disables the Application Profile service at this server instance.

• Activity Session Service – enables or disables the service at this server, and sets the default timeout for activity sessions initiated at this server.

• Scheduler Service – enables or disables this service at the server.

• Work Manager Service – enables or disables this service at the server.

• Object Pool Service – enables or disables the object pooling service at this server.

• Staff Service – enables or disables staff service at this server.

Generally, all of the programming model extension services are enabled at every application server where the programming model extensions are installed. You should also examine the corresponding configuration controls for these services in the application and in the resource definitions for the service itself.

Configuring the Application Extensions

The application configuration extensions show up within your application's configuration.

• Last Participant Support Extension – enables support for a mixture of any number of two-phase commit resources and at most one single-phase commit resource in the same transaction. While WebSphere can coordinate one single-phase commit resource in a global transaction along with any number of two-phase commit resources, their inclusion can lead to a slightly higher risk of heuristic outcomes. Thus, you can select to enable this capability for individual applications depending on whether you can accept that additional risk.

• Application Profile – allows you to create one or more application profiles for this application, and to associate them with one or more Task identities.

Configuring the Resource Extensions

Many of the services introduced by the programming model extensions are treated as independent resource managers – managing the resources of their respective service. Thus, you do the majority of behavior control configuration through the Resources task group.

Work Managers

WebSphere ships with a default work manager – see The Deferred Execution Service section of Chapter 11 for more information about work managers. You can change the configuration for this work manager or create other work managers through the Work Manager task.

You can control a number of settings for each work manager.

• Name – is the name of the work manager as displayed on the admin UI.

• JNDI Name –the name by which this work manager is known in the JNDI namespace.

• Description – describes the work manager instance; what makes it distinct from other work managers.

• Category – is not used by WebSphere; you should leave this blank.

• Number Of Alarm Threads – defines the number of alarm threads you want. Typically this will determine the maximum number of asynchronous work activities that can be scheduled to be started at exactly the same time.

• Minimum Number Of Threads – establishes the minimum number of threads to hold on stand-by in the thread pool for parallel asynchronous processing.

• Maximum Number Of Threads – specifies the maximum number of threads that can be created in the thread pool for parallel asynchronous processing.

• Thread Priority – sets the thread priority for the work that is managed by this work manager.

• Growable – indicates whether the thread pool can grow temporarily beyond its maximum thread pool size.

• Service Names – identifies what services will be involved in setting service contexts on any asynchronous work.

Schedulers

A Scheduler can be created to manage work that has been scheduled to execute on a particular day or time. Scheduled tasks are recorded persistently, and will be executed as scheduled. Scheduled work will be executed by any Scheduler in any application server that shares the same underlying task database (as defined in the configuration for each Scheduler). Work will be distributed to various Schedulers based on which is least loaded at any given time.

Each Scheduler is associated with a particular Work Manager, and derives its work scheduling, thread limit, and priority configurations from that work manager. You will want to create different Schedulers if you want different thread limits and priorities.

• Name – the name of this Scheduler

• JNDI Name – the JNDI name used to look it up

• Description – a textual description that can be used to communicate about it to other administrators

• Category – is not used by WebSphere; you should leave this blank.

• Datasource JNDI Name – the JNDI name of the datasource that is used to hold the persistent state of this Scheduler; scheduled tasks are recorded persistently to ensure they can be executed at any time in the future, as scheduled, even if the server on which it executes is restarted

• Datasource Alias – the user alias to be authenticated when using this datasource

• Table Prefix – use this to differentiate between different Scheduler entries if sharing the same database amongst multiple Schedulers

• Poll Interval – specifies the frequency with which the Scheduler will look for new task entries in the scheduler database

• Work Manager – the work manager associated with this Scheduler

Object Pools

Object pools are used by applications to create reusable object instances to avoid the overhead of creating new instances. You can configure these pools as a resource through the Admin console.

• Name – the displayed name of this object pool

• JNDI Name – the JNDI used to look up the object pool

• Description – a textual description used to communicate about the object pool to other administrators

• Category – is not used by WebSphere; you should leave this blank.

Staff Services

The staff services are a plug-in to the business process manager for mapping the organizational relationships of business processes to individual users and groups defined in the user repository.

A default staff service provider is shipped with WebSphere and can be used with users and groups in an LDAP user registry.

The primary thing you can configure about the staff service is the mapping to the LDAP schema. This is done through an XSL transformation that you define. To change the default mapping, you can create your own XSL file and configure it with the staff service provider:

Select the New button to define a different transformation:

You can then enter the location of the XSL file containing your schema transformations.

Additional Configuration Options

The administration extensions for PME also extend various existing configuration options. The primary example of this is where the Transaction Service configuration for an application server introduces a new option for controlling the logging of heuristic outcomes – something that may be important if a mixture of single-phase and two-phase commit resources are used in the same transaction.