Application Profiles

With all of this access intent information now available, properly applying it at the right time during execution is the next thing to understand.

The J2EE 1.3 model for describing information about components (EJBs, servlets, and so forth) involves using deployment descriptors. This is a very good pattern in that it extracts this kind of information into separate XML files that can be changed without changing the underlying component implementations or client programs that use those implementations. This creates a model where component reuse is encouraged. The declarative style can also be beneficial for specifying contractual information that does not fit into the code. Looking at the deployment descriptor of an entity bean, for example, to see what the transactional requirements or expectations are, is very natural to those who have been doing EJB programming for any period of time.

J2EE vendors often necessarily add their own extensions to the base deployment descriptors. WebSphere adds deployment descriptor extensions at the application, module, bean, and method levels for various features that it supports, which complement and augment the base specifications. These are included in separate extension files. In fact, the files ibm-ejb-jar-ext.xmi and ibm-ejb-jar-ext-pme.xmi represent extensions to the base deployment descriptor that are provided by the base application server and the Enterprise Edition respectively.

The declarative model, however, is largely static. The ibm-ejb-jar-ext.xmi extensions support only a single set of extensions per entity bean. The runtime then uses those extensions to make decisions about managing resources and interacting with databases and other resource managers. The problem is that the decisions made for a given deployment of an entity bean, for example, are not always the same. What if the decisions about entity bean resource management should change from application-to-application or from calling client to calling client? For example, what if there were some session beans in the Plants-By-WebSphere application that access the Customer entity bean using optimistic transactions, and other session beans in the application that need a pessimistic transaction for the same Customer entity?

A simple solution to this is would be to have multiple deployments of our entity bean, each with different statically defined descriptors and extensions. This means that each different usage of a given resource might use a different deployed version of that resource (let's stick with entity beans for this discussion). While this is technically feasible, it is not practicable because the number of combinations needed is untenable and the impact on the caller is too significant.

We could certainly change our deployment tooling and deployment descriptor extensions to have multiple sets of deployment descriptor extensions that need to be used at runtime. However, this is just part of the solution; we still need a way to decide which of these sets of extensions are to be used in any given situation.

The problem should now be clear. We need a way to dynamically alter the information that the runtime uses, based on the usage pattern (profile) of the caller (application).

An Application Profile provides a way for applications to suggest to the runtime which among the possible sets of hints should be used for any given server operation. The basic pattern at run time is as follows:

1. Sometime during the execution of the application a label or task name, which is the key to a set of hints, gets attached the thread of execution.

2. Later in the execution sequence, pieces of the runtime that are Application Profile service aware, look on the thread of execution, get the task name if it exists, and use those hints, which are accessed via the task name.

The pattern above deserves a bit more explanation. The next sections goes into detail on this and describes how to set up an application to use the Application Profile service so that the above activities occur during application execution. If these do not occur, we get the default behavior of access intent as described earlier.

The Application Profile Service

The Application Profile service supports configuration, propagation, and presentation of named units of work or tasks. A task designates a unit of work at the business level. In Plants-By-WebSphere, creating a new user, creating a new order, and adding an item to a shopping cart all represent potential tasks, or named units of work. As we will see shortly, a task can be associated with a session bean, session bean method, servlet, servlet method, or J2EE client. A task can be designated wherever the business level unit of work is known and initiated in the runtime system.

The Application Profile service can be used in two ways, programmatically or declaratively.

Bean providers can use the Application Profile service programmatically to tie different ways in which the same bean can operate to a specific task name. The name is a logical label in the code, which is linked by the application assembler via deployment descriptor extensions to a real set of attributes (the profile) that the runtime will use to make decisions. Programmatic use of the Application Profile service might look like this:

 TaskNameManager tnm = (TaskNameManager) initialContext.lookup(                       "java:comp/websphere/AppProfile/TaskNameManager");    //...   if (someCondition) {       tnm.setTaskName("someTask");   } else {       tnm.setTaskName("someOtherTask");    //... 

The above snippet attaches either someTask or someOtherTask to the thread of execution. Exactly how this impacts on access intent will be described later. While bean providers can programmatically put the proper task name onto the thread of execution, it is more flexible to do this work declaratively.

The declarative style is similar to how transactions are managed using the container-managed style. This style of leveraging the Application Profile service is less intrusive from a source-code perspective. This should lead to more intensive and tuned usage of the service. Examples of how to create tasks in the assembly tool and associate them to specific application profiles will be provided in the upcoming section.

The next section will describe how to use Application Profile and the tasks concept, which was described above, to allow dynamic and specialized usage of access intent information. Access intent is the primary use of Application Profile in WAS 5.0.

Note

Beyond version 5.0, it is likely that additional usages of Application Profile will be supported. The whole concept of more dynamically applying information about components based on intend usage patterns is one that has great potential and one that is essential if we are to truly create more flexible and reusable components.

Access Intent Using Application Profile

Now we need to pull it together. How do we use the combination of the access intent support provided by WebSphere and the Application Profile service to control backend interactions in a fine-grained way?

This process of pulling it all together will be described in terms of three activities. These are:

• Creating the possible profiles

• Identifying the tasks

• Mapping the tasks to profiles

This process can be done top-down, bottom-up, or meet-in-the-middle. What is coming in the next sections is a top-down view, but it is clear that different methods of arriving at the answer will be used.

Let's return to some examples to show how this might be done. These examples are somewhat simple to introduce the concept with minimum additional clutter.

Creating Application Profiles

For the example, we will use the Order entity bean from the Plants-By-WebSphere application. Let's assume that we have analyzed all the users of the Order entity bean, such as the Catalog session bean and ReportGenerator session bean, and determined that leveraging different access patterns will be beneficial to overall system performance and throughput. In the example, the Catalog session bean would desire to have access to the Order entity bean using an optimistic update access intent while the ReportGenerator session bean can work best with a specialized access intent that supports the high volume of reading that is part of the business logic of this session bean.

Note

The ReportGenerator bean is another session bean from the full-blown Plants-By-WebSphere application. You can find the source for this bean in the source code for Chapter 9 on the CD.

We start by creating a new Application Profile for eventual use by the Catalog session bean. Select the of the and right-click, then select from the pop-up menu. Fill in the name of the profile and a short description as shown and press

• Application Profile

• EJB Module

• New

• Apply:

We will come back later to fill in the tasks.

Create the HighVolReadProfile the same way. After this, we have two profiles created, but have not really wired them into the rest of the application yet:

Once these are created, the specific access intents that are desired for this profile can be created. First, select Access Intent under the HighVolReadProfile, right-click and select New.

This will bring up a screen that looks similar to the one from the earlier section where we created an access intent. Because we are now creating the access intent as part of an application profile, the policy can now be applied to an entire entity bean rather than a set of methods. Instead of considering the method that causes the bean's data to load from the backend, the application profiling service will use the application profile associated with the active task to determine the correct access intent.

Below is the screenshot of the completed access intent customization named HighVolReadIntent that goes with this HighVolReadProfile:

You can see that we have taken the wsOptimisticRead access intent policy set and tuned it using the same style as we learned earlier.

On completing this step, we can create the OptimisticUpdateProfile in the same way, creating the OptimisticUpdateIntent that describes the access intent policy. The assembly tool is shown below with both the profiles ready to be put to use:

These two profiles are attached to different intents. We have two different ways to access the Order entity bean specified and carried by the application profiles that have just been set up. They are at the application level. Even though they are specific to how we will want to have the Order entity bean interact with the database, they are at the application level. This allows them to be used by the various callers to the Order entity bean.

We have now declared two profiles that can be used when interacting with this entity bean. The next step is to identify the tasks that represent the different callers of this entity bean, which might want to use different profiles to access the entity bean.

Identifying Application Tasks

Tasks represent points in the application where we know a set of interesting and useful things about the application that we want to communicate to the underlying application server. In more concrete teams, this is where we know the intents that we want to use to provide as hints to the runtime. We communicate these hints downstream to give the application server the opportunity to act differently in terms of how it operates. Tasks can be established based on servlets, clients, or EJBs, with the possibility of individual EJB methods having different tasks associated with them.

Getting back to our example, we must create some tasks and map them to specific session bean methods to get the desired effect. Start by creating a task. Right-click on Container Tasks, and click on New. This will bring up the following entry view:

Fill in this view and select the methods that are going initiate the request to do the high volume reading. This time, we will pick specific methods as shown here:

These methods will actually do the high volume reading of the Order entity bean.

Shown in the next screenshot is the creation of a task for a couple of methods on the session bean that wish to have the high volume read behavior if possible. Let's name this task HighVolReadContainerTask to keep it simple:

The Run as specified radio button is selected to indicate that this task is to be applied and is not to be overridden by any task that may already be present when the methods are executed. This implicitly suggests that anyone calling the named methods cannot change the task that is used in downstream calls by the runtime. A more comprehensive example might indicate some methods that are to pass through tasks that the caller might have suggested and some patterned like the example, which indicates specific task names for specific methods.

Another one of these tasks is created named OptimisticUpdateContainerTask and is mapped to methods on the session bean that drive updates. The same steps just described are repeated and another task is created.

Now that we have defined tasks and we have the profiles, all that is left is to wire them together and inform the system which profiles should be used by which tasks.

Mapping the Tasks and the Application Profiles

Describing the profile to use for specific tasks is probably the easiest of the activities. It consists of simple mapping from the profiles and tasks that we created. While there are a couple of ways to do this, one simple way to begin this process is to go to the Application Profile selection that is at the application level or top level of the .ear file that you are working on, and start there. You can see in the following screenshot that you can associate the things we have talked about before. In the example screenshot, we have tied HighVolReadProfile to HighVolReadTask:

The same step is repeated to map the other task. With both of the mappings complete, we have a view like this:

Now we are done going through what it takes to set up and use application profile and access intent. We now have to set up our application to leverage two specific application profiles. The signal to use these profiles comes from the task mappings. The use of the downstream intents is based on the task that is active, and the profile that it points to, when backend interactions are done by the runtime. All that is left is to execute is the application.

When the application is executed, the tasks will be placed onto the thread of execution when the session bean or identified component is executed. This task name then remains on the thread of execution and is leveraged by the runtime when it needs to do operations that involve access intent. Different behaviors from the entity beans can be expected based on the set of access policies that are leveraged.

Pulling these pieces together yields a chart like the one shown below:

We have been through these concepts using a specific path. This diagram shows the key concepts we have talked about, suggesting the relationships between these concepts, and providing a view of what some of the other paths might be.

A task, as we discussed, pulls together a number of units of work that are the same or similar in terms of the needs they have when it comes to interacting with the backend systems. A task separates units of work from the profiles and provides a level of indirection that simplifies tuning and changing how the applications are configured.

An Application Profile provides a way to link together a task to a specific set of intents. An Application Profile is the way that we can get multiple sets of intents for a given entity bean. What might be a bit confusing is that multiple tasks can be tied to a specific Application Profile. For example, we could have had many tasks that all mapped to a specific profile. This might occur if we have developers identifying units of work and we have someone else during deployment testing actually deciding which tasks best map to which profiles.

Access intents do not map one to one with entities. An entity can have many access intents, which necessitates many Application Profiles. An entity will be configured exactly once per application profile.

A number of new abstractions have been described in this section, which will provide us with a great deal of flexibility in configuring our applications to achieve the maximum efficiency possible.