Let us identify the classes that participate in the realization of the Check Authorization extension flow. This will comprise the parameterized classes: 〈Boundary〉, 〈Control〉, and 〈Entity〉, which realize the 〈Perform Transaction〉 use-case pattern. These classes are shown on the left of Figure 14-3. We put these classes in brackets, 〈 〉, to indicate that they are parameters to the Handle Authorization use-case slice. We subsequently bind these parameters using pointcuts.

Figure 14-3. Candidate classes: Handle Authorization.

In addition, you need classes to provide the authorization capability. These classes are listed on the right-hand side of Figure 14-3. The Authorization Handler coordinates the interactions between classes that are involved in this use-case realization. The Access Control List class keeps track of which user is able to do what with the system. The Session class tracks the user actions from the time she logs in to the time she logouts.

You normally start the analysis of a use-case flow at the point when the use-case flow is triggered. For basic flows, the triggering event is typically the result of some actor initiation. For alternate flows, or for that matter, extension flows, the triggering point occurs at the point designated by the pointcut. Thus, the first step in analyzing an infrastructure use-case extension flow is to determine where the pointcut will be pointing to in the realization of the 〈Perform Transaction〉 use case.

The basic flow of the 〈Perform Transaction〉 use case is shown in Listing 14-1. It describes the pattern involving how an actor retrieves and displays some data on the form. Please note that Listing 14-1 describes only a general and simple case. There are, of course, many variations to this simple case, and you can describe them if necessary using alternate flows or extension flows in a separate infrastructure use case.

The realization of the 〈Perform Transaction〉 use case is shown in Figure 14-4. It contains actor instances and class instances, each parameterized with brackets. The interaction between the instances is described simply, as follows: the actor instance performs a request through a 〈Boundary〉 instance, which delegates the processing to a 〈Control〉 instance. This 〈Control〉 instance invokes some data-access operations on an 〈Entity〉 instance. The 〈Boundary〉 instance then displays the results.

Figure 14-4. 〈Perform Transaction〉 use case: interaction diagram.

You now identify the context for executing the authorization check. This is based on the Check Authorization extension flow in the Handle Authorization use case (Listing 14-2).

PerformingTransactionRequest.

PerformingTransactionRequest = 〈Perform Transaction〉.Perform
Request.

performingRequest = call (〈Control〉.〈performRequest〉 )

〈handleRequest〉 { around (〈performingRequest〉) checkAuthorization}

Now that we have identified where the checkAuthorization extension needs to be executed within the 〈Perform Transaction〉 use-case realization, we can describe the interaction between the participating class instances as shown in Figure 14-5. Figure 14-5 contains two frames. The first is labeled as follows:

around  (〈performingRequest〉) checkAuthorization

Figure 14-5. Check Authorization interaction.

It represents the operation extension inserted into the 〈handleRequest〉 operation of the 〈Boundary〉 class. This operation extension gets the 〈Boundary〉 to check authorization through the AuthorizationHandler. The AuthorizationHandler instance gets the user from the Session instance. You can assume that the user details have been associated with the Session instance when the user logs in to the system. This is achieved through the realization of the Login basic flow of the Handle Authorization use case. Based on the user details (i.e., user Id, user role), it checks the user’s privileges through the Access Control List. If the user has the required authorization, the rest of the 〈handleRequest〉 proceeds. Otherwise, an error is raised.

Proceeding with the rest of the 〈handleRequest〉 in the 〈Boundary〉 is represented by the second frame. AOP provides a proceed keyword to achieve this.

The way you describe the interaction between the instances participating in an infrastructure use case is the same as that for a normal application use case. The usual practice applies. For example, an entity instance should not invoke a boundary instance subscribes to changes in the entity instance). In general, you should let a control instance do most of the coordinating work.

Describing Class Responsibilities

From the messages between the instances, you can identify the responsibilities of the participating classes. You can summarize the class responsibilities and the pointcut definitions in a class diagram, as shown in Figure 14-6.

Figure 14-6. Participating classes in Check Authorization extension flow.

Each box in Figure 14-6 represents a partial definition of classes relevant to the realization of the Check Authorization flow. You must explore the complete set of flows to find all responsibilities of each participating class. This takes place iteratively across the project life cycle. Note that the pointcut is not shown in the class diagram below. It is shown later when we define the aspect that contains the class extensions specific to the Handle Authorization use case.

Consider if there are classes that are functionally related to each other. By functionally related, we mean that they are expected to evolve and change together. You put these classes in a service package. Since you are now dealing with the infrastructure, we call such packages infrastructure service packages.

Consider if there are reusable classes. If so, you can put them in a package in a lower layer. These packages support different infrastructure service packages, and we call them infrastructure support packages. Infrastructure services and infrastructure support form two layers in the infrastructure.

Frequently, infrastructure support packages are provided by the underlying platform in the form of some middleware. This means that you will seldom need to develop them. Instead, you will just make use of them through the infrastructure service packages. These packages are like the glue that binds the application to the underlying infrastructure.

After making these considerations, you can package the infrastructure classes as shown in Figure 14-7.

Figure 14-7. Candidate classes: Handle Authorization.

The Authorization Handler and the Access Control List are for the sole purpose of handling authorization and are closely related. Hence, we put them in an Authorization infrastructure service package. The Session and User classes are used by other infrastructure services, such as auditing and profiling. Since they are reusable, we put them in an infrastructure support package.

Now that you have determined where the classes that realize the Handle Authorization use case should reside in the element structure, you must determine how they are added. The Session Management classes are fundamental to several infrastructure services and are therefore added through a non-use-case-specific slice named Session Management, as depicted in Figure 14-8. The Authorization Handler and the Access Control List are added through the Handle Authorization use-case slice.

Figure 14-8. Slices of the infrastructure layers.

Let us take a closer look at the Handle Authorization use-case slice (see Figure 14-9). It comprises the classes and features that are specific to the realization of the Handle Authorization use case. It contains a collaboration (also named Handle Authorization) that describes the interaction between the participating classes. It contains the Authorization Handler and the Access Control List.

Figure 14-9. Use-case slice: Handle Authorization.

The Handle Authorization use-case slice also contains an extension of the 〈Boundary〉 class that it extends. This class extension is housed within an abstract aspect, HandleAuthorization (depicted in italics). It is abstract because the pointcuts, though identified, are not defined; that is, the pointcuts are named but no expression is spelled out.

The Handle Authorization use case has been analyzed with reference to a 〈Perform Transaction〉 use-case pattern. Thus, you find that a number of parameters are currently unbound. These parameters are Boundary, Control, and HandleRequest. Recall in Chapter 9, “Keeping Extensions Separate with Pointcuts,” we described two ways to express parameters:

Both are possible, but in this case, we want to take advantage of the first method by using aspect-generalization capability. Thus, the parameters Boundary, Control, and HandleRequest are expressed as abstract (depicted through italics) in Figure 14-9. Accordingly, the HandleAuthorization aspect is also abstract. Thus, you have a prebuilt use-case slice waiting to be specialized and attached to an actual use-case slice. The next section demonstrates how you can specialize the HandleAuthorization aspect.

As an example, let’s assume that you want to apply the Handle Authorization use case to the customer package. Thus, you can specialize the abstract HandleAuthorization aspect in Figure 14-9 into a concrete CustomerApplicationAuthorization aspect.

Let’s look at how you can define the pointcut expressions for the CustomerApplicationAuthorization aspect. Suppose you want to subject all the boundary classes to authorization checks. You can define the Boundary pointcut as follows:

Boundary = customer.app.«boundary» *

We have just introduced in the pointcut value expression a matching criteria based on the stereotype: «boundary». Thus, customer.app.«boundary»* refers to all classes within the customer.app package that are of the stereotype «boundary» of any name. You can see that the matching criteria need not be restricted to element names. In general, you can use element names, stereotypes, and tag values. In fact, you can use any modeling mechanism that distinguishes one element from another.

Since most programming languages currently do not have constructs for stereotypes and tag values, the naming convention during implementation must have some prefix or suffix to indicate the kind of stereotype and tag values the element is mapped from.

In AspectJ, pointcut expressions can use the + character to refer to all the children of a particular class. You can define the Boundary pointcut as follows:

Boundary = Form+

This means that you are applying the aspect on all children of the Form class in the customer package. You can likewise define the pointcut to bind Control to all Handler classes as follows:

Control = Handler+

In this particular case, we do not restrict which package Control classes belong to. This is because Control classes might not be limited to the customer.app package. They may reside in the lower domain-specific layer as well as in the application-specific layer.

You can now summarize the pointcut expressions for the CustomerApplicationAuthorization aspect, as shown in Figure 14-10.

Figure 14-10. Specializing the HandleAuthorization aspect.

In 14-10, the responsibilities 〈handleRequest〉 and 〈performRequest〉 are bound to wildcards. This means that the authorization will be checked for every request that the actor initiates. In reality, you may want to impose restrictions on the kind of request you want to check. These restrictions will be project-specific.

AOP is but one technique for you to keep infrastructure use cases separate. Object-oriented frameworks such as J2EE provide an alternative solution. In J2EE, a servlet is a Java program that executes on a HTTP Web server. It handles requests from an HTTP client (e.g., a Web browser) and generates responses typically as HTML output. The J2EE servlet specification provides a filtering mechanism that allows you to implement crosscutting concerns such as authorization at predetermined points. A filter dynamically intercepts requests to a servlet and responses from a servlet. The filter can modify requests or responses or both. Typically, filters themselves do not create responses, but instead provide universal functions that can be “attached” to any type of servlet.

Simplistically, the operation of the filtering mechanism for J2EE servlets works as shown in Figure 14-11.

Figure 14-11. Servlet filter mechanism.

Instead of getting the servlet to process a request from an actor directly, the filtering mechanism passes the request through a series of filters before it reaches the servlet. The response from the servlet then passes through the same series of filters in the reverse direction. Each filter can act based on the request and even modify the request and response parameters. It can also prevent the request from flowing downstream and return the result immediately. As you can see, the filters are lined up like a chain, so in J2EE, they are collectively called a filter chain.

This servlet-filter mechanism is an example of the Composition Filters approach to separate concerns [Bergmans et al. 2001]. The servlet-filter mechanism can be used to implement the authorization use-case slice. In this case, you can map the abstract HandleAuthorization aspect we discussed earlier (see Figure 14-10) to an abstract filter. This abstract filter deals with user requests. In addition, you need a corresponding concrete filter to deal with authorization specific to the customer application as a counterpart to the CustomerApplicationAuthorization aspect (see Figure 14-10).

Figure 14-12 shows how this is achieved. The left-hand side shows two interfaces provided by the J2EE servlet library. Simplistically, the Filter interface defines a doFilter() that accepts a request and produces a request.

Figure 14-12. Classes participating in HandleAuthorization implemented using servlet-filter mechanism.

The FilterChain interface defines an operation with the same name, doFilter(). This operation gets the next filter in the filter chain to perform doFilter().

The right-hand side of Figure 14-12 shows the classes you will implement. They are both counterparts of the HandleAuthorization and CustomerApplicationAuthorization aspects respectively. The HandleAuthorization filter has two operations: doFilter() is abstract, and the checkAuthorization() operation performs the actual authorization checks. It accepts the names of the Boundary and Control classes and the use-case operation being initiated by the actor as input. Based on these three inputs, it determines if the actor has sufficient authorization.

The detailed sequence of events for the doFilter() operation in the CustomerApplicationAuthorization class is depicted in Figure 14-13. It first extracts parameters from the filter request. The request contains strings indicating which boundary class, which control class, and which action the actor is initiating. The CustomerApplicationAuthorization instance calls the checkAuthorization() operation defined in its parent. If authorization passes, it calls the next filter in the filter chain.

Figure 14-13. Interaction diagram for HandleAuthorization implemented using servlet-filter mechanism.

Thus, the HandleAuthorization filter provides generic authorization, and the CustomerApplicationAuthorization filter attaches it to actual application classes. This mirrors the approach we presented earlier using AOP. Specifically, the doFilter() operation is analogous to an around advice in AOP, and the doFilter() operation on the FilterChain is analogous to the proceed keyword in AOP.

What you see here are two ways for you to design and implement infrastructure use case. Let’s compare the solutions you can achieve AOP with servlet filters. Both are able to keep authorization concerns separate in an unintrusive manner. The servlet filter defines a fixed execution point (known as a join point in AOP) whereby additional behaviors can be executed, specifically by implementing the Filter interface and the doFilter() operation.

AOP is more general, and with powerful primitives to express join points, it can be used to extend different parts of the system with additional behaviors. Thus, AOP is more flexible. But flexibility must be supplemented with guidelines. You do not want the owner of different use cases to add authorization behaviors at different places without architectural control. The 〈Perform Transaction〉 use-case pattern gives you a reference to anchor the pointcuts for your infrastructure use cases.

Whichever way you choose, whether AOP or filters, you still go through the same steps of use-case specification, use-case analysis, and refinement of the element structure, which we discussed earlier in this chapter. When it comes to design and implementation, you choose the most appropriate technique. Consider if a fixed-point extension offered by servlet filters is sufficient. If not, choose AOP techniques to find a better extension point.

Handling authorization is a common capability needed by most systems, so it makes sense to develop a component for it. Your system should also provide the means for you to plug in this authorization component. This is achieved through the Handle Authorization use-case slice, which is depicted in Figure 14-14.

Figure 14-14. Authorization component.

The Handle Authorization use-case slice has a HandleAuthorization aspect, which can extend existing components with a required interface, IAuthorizationHandler, whereby you can plug in a AuthorizationHandler component. We have shown two approaches to extending components: through AOP (specifically use-case slices) and through filters.

With the AOP approach, you can extend each component individually. With the filter approach, you extend many component at once, since all calls to these components go through the filter mechanism first. This filter mechanism can of course be introduced into the system through a use-case slice.

Sometimes, infrastructure use cases (specifically, their extension flows in use cases, which are translated to operation extensions) are attached to the same execution point. Execution point A is such an example. In such cases, you must determine whether they are indeed attached to the same execution point. Figure 14-15 is, after all, a relative high-level depiction of the interactions between instances. You need to zoom in further to uncover more detailed interactions. Thus, Figure 14-15 is expanded into Figure 14-16.

Figure 14-16. Expanded 〈Perform Transaction〉 interaction.

In Figure 14-16, the 〈handleRequest〉 operation has two steps:

This refinement shows that the authorization extension is executed at a different execution point than in the other two infrastructure use cases. The authorization extension occurs at the beginning of the 〈handleRequest〉 operation, whereas caching and distribution extensions occur around the getInstance() operation.

The objective of caching is to reduce the need to create 〈Control〉 references every time a 〈Control〉 instance is needed. The objective of distribution is to hide the fact that the 〈Control〉 instance is in reality executing on a different processing node. Though they have distinct purposes, they execute around the getInstance() operation.

In conventional programming, you can indicate the order in which infrastructure use cases are attached by simply ordering your programming statements in the existing code. However, with aspect orientation, you are overlaying operation extensions on top of existing operations, so you must define how overlaying is conducted. For example, you might want the distribution to be overlaid first and caching of remote instances on top of that. In this case, you have distribution as an extension of the 〈Perform Transaction〉 use case and caching of remote references as an extension of distribution. In use-case modeling, this is modeled as shown in Figure 14-17.

Figure 14-17. Extension of extension.

Please note that extensions of extensions do not necessarily lead to having aspects of aspects or operation extensions of operation extensions (i.e., advices of advices). This is because operation extensions are meant to be small. They should delegate the actual work to other classes, and you subsequently overlay on top of these classes. This is illustrated in Figure 14-18.

Figure 14-18. Use-case slices extending use-case slices.

On the left, you see the 〈Boundary〉 class that participates in the realization of the 〈Perform Transaction〉 use case. To the right of the 〈Boundary〉 class is a Handle Distribution slice. It has an aspect named Distribution, which contains a 〈Boundary〉 class extension. This contains an operation extension that replaces local calls with remote calls in the original 〈Boundary〉 class on the left. Now, the operation extension in the 〈Boundary〉 class extension does not create the remote instances. Instead, it delegates the responsibility to a class named RemotingHandler.

To the right of RemotingHandler, you see the Cache Remote References use-case slice. In the same manner as above, it has a Caching aspect that adds an operation extension into the RemotingHandler to cache remote instances. This is achieved using the CachingHandler class. Thus, you see that in this case, you can avoid overlaying aspects on top of aspects. The implementation is much easier to understand.

Sometimes, you do have extensions at the same exact point. For our example, we have a Logging extension use case and a Handle Distribution use case on the 〈Perform Transaction〉 use case, as depicted in Figure 14-19.

Figure 14-19. Extensions that are separate.

Let’s say both extensions occur at the same point. They need to be independent and there should be no ordering between them, otherwise, the design becomes complicated. The situation becomes worse when you want to parameterize pointcuts to cover a large number of classes and operations. Thus, you should have either extensions of extensions realized, as shown in Figure 14-18, or extensions where order is not important, as shown in Figure 14-19.

In addition to considering multiple infrastructure use cases on top of the 〈Perform Transaction〉 use case, you also need to consider the variations that may occur in the application layer. The interaction in Figure 14-15 considers only the basic flow of the 〈Perform Transaction〉 use case. The variations can be effectively modeled as alternate flows of this basic flow.

You must consider what are the acceptable behaviors of the infrastructure use cases to such variations and handle them accordingly. This may result in:

Both will lead to identification of more operation extensions and pointcuts for the infrastructure use cases. To resolve potential conflicts, you need to consider multiple use-case slices and aspects at once, as we demonstrated in this chapter. The benefit you get with use-case modeling is that you can quickly get an overview of the possible conflicts and refactor them with a use-case diagram such as in Figure 14-17 and Figure 14-19.