Chapter 19. Solutions
A solution provides the means of satisfying business requirements and providing value to the enterprise. This book, as a whole, focuses on the architecture of solutions, and this chapter addresses application of the material that has been covered to the architecture of solutions.
To facilitate the discussion, we will employ two examples. One will be the query of a book database based on the query reference architecture discussed in Chapter 4. This example is simple enough that it requires little explanation. The other is a service to validate an individual’s membership in a health care plan on a given date. This example is considerably more complicated and requires some explanation.
Solution Architecture
A solution architecture lays out the structure and organization of the solution. Its primary elements are those of any architecture: process models, an architecture pattern, and mappings of the process models onto the architecture pattern.
The solution architecture identifies the business processes impacted by the project and defines their structure in the solution. It identifies the participants (both people and systems) and, by means of the architecture pattern, defines how they will be organized and will communicate with one another. Finally, the solution architecture defines how the business processes map onto the participants in the architecture pattern, detailing the roles and responsibilities of the participants.
At this point, let’s take a look at a solution architecture for one of our examples, the Membership Validation Service.
Membership Validation Service
Membership Validation Service Requirements
In the health care arena, there are occasions when it is necessary to determine whether a given individual is covered by a particular health plan as of a given date. This may occur during the processing of a health care claim or when a health care provider, prior to performing a service, needs to determine whether an individual is presently covered.
The membership validation service will be provided by Nouveau Health Care, an enterprise that is both a health plan issuer (i.e., an insurance company) and an administrative processing house for other health plan issuers.
The service will be made available to a number of parties: claims processors within the enterprise, claims processors external to the enterprise, and health care providers. Internal access will be provided via SOAP with a JMS transport, and external access via SOAP with an HTTP transport. Parties using the service must provide credentials and be authenticated and authorized. The service must support multiple types of credentials including userid/password pairs and digital certificates.
The membership validation service provides a single operation at its interface (Figure 19-1). Input to this operation comprises identifying information about the health care plan issuer, the plan itself, the member whose membership is being checked, and the date of service for which validation of coverage is being requested. The operation responds by indicating whether the member identifier has been found associated with the indicated health plan and whether the membership in the plan was valid on the date specified.
Figure 19-1. Membership Validation Service Interface
The service is intended to be a wrapper around existing capabilities for validating membership. Consequently, the service must be capable of interacting with a number of back-end systems. Some of these systems are local to the Nouveau Health Care. Others belong to third-party business partners for which the Nouveau serves as an administrative processing center.
The local systems are databases that will be accessed via JDBC. There are several such systems, each supporting a different set of health plans. One of these external systems has already been identified and will be accessed via a SOAP over HTTP interface. Others are, at this time, unidentified, but provisions must be made for their incorporation at some future point. Although the details of the future interfaces have not been defined, it should be assumed that the information content of the ValidateMembershipRequest is sufficient to support the interaction. Access to all back-end systems will require credentials for authentication and authorization. Credentials will either be userid/passwords or digital certificates.
Membership Validation Solution Architecture
In the membership validation example, there is a single business process: Validate Membership (Figure 19-2). The process is very straightforward. It takes in the information for the query and, using a cross-reference table maintained by the service, determines the back-end system to which the request should be directed. It then reformats the request as required by the back-end system, submits the back-end query, and obtains the answer. The answer is then converted into the format specified by the service and returned.
Figure 19-2. Validate Membership Process
Note that the process also indicates what should happen if exceptions arise. This defines the business process response to problems. In this example, the business process response is to simply announce that something went wrong. However, in many business processes there are alternate courses of action that are expected to be pursued when specific problems arise. It is important to capture these as part of the process definition.
The architecture pattern for the service is shown in Figure 19-3. The service consumers will interact with the service using SOAP with either JMS or HTTP as the transport. The service interacts with back-end systems in a variety of ways. The local systems are databases that will be accessed via JDBC. The partner system that has been defined at this point has a SOAP interface that utilizes HTTP as a transport. Other partner systems have yet to be defined, but the service architecture should be designed in such a way as to readily accommodate new back-end interactions.
Figure 19-3. Membership Validation Architecture Pattern
The mapping of the process onto the architecture pattern is shown in Figure 19-4. There are three significant design decisions that were made in defining this mapping. One is that the entire interaction from service consumer to issuer system and back will follow the Multi-Party Request Reply pattern described in Chapter 17. The second is that the issuer-system cross-reference will be part of the Membership Validation Service. The third is that any exception raised within the service will result in the return of a SOAP fault.
Figure 19-4. Membership Validation Process-Pattern Mapping
Refinement
The solution architecture, of course, is not a complete solution. Much detail has to be added in order to obtain a working solution. But, at the same time, adding the detail should not alter the architecture. This raises the question as to how you go about adding detail and, at the same time, ensure that you are not altering the architecture. The answer is by using the process of refinement.
Refinement means adding detail without altering structure. This concept, applied consistently to the three architecture perspectives, ensures that the architecture itself is not altered. This, in turn, ensures that any reasoning and analysis that were applied to the architecture are still valid for the completed solution.
In reality, it is not always possible to complete the implementation of a solution through refinement. Issues can arise during implementation that were not considered in the architecture and require a modification of the architecture in order to address them. When these situations arise, raise the issue to the architect and let the architect determine the appropriate modification to the architecture. It is important to do this because the modifications may have consequences that cannot be anticipated without the full architectural perspective.
Process Model Refinement
Refining a process model adds internal detail to individual activities but does not alter the original structure of the activities. Figure 19-5 shows an architectural process model and a proper refinement from the implementation. Internal structure has been added to activity B, but this activity still follows activity A and, no matter what internal path is taken within the activity, is succeeded by activity C.
Figure 19-5. Process Refinement Example
The most common violation of process refinement typically arises as a result of exceptions whose handling was not specified as part of the process model. At this point, it is important to re-engage the architect (who may, in turn, go back to the business) to determine the appropriate business process response to the exception.
Architecture Pattern Refinement
Refining the architecture pattern adds internal detail to the elements of the architecture pattern without altering the original structure. Figure 19-6 takes another look at the ATM example discussed back in Chapter 3. It supposes that the original architecture specification indicated only that there would be an ATM system and left the internal structure of that system unspecified. The refinement, used in the implementation, indicates that the ATM system comprises two types of components: ATM Machines and an ATM Server. ATM Machines interact with the ATM Server which, in turn, interacts with the Bank Servers.
Figure 19-6. Architecture Pattern Refinement Example
Architecture pattern refinement precludes adding components that are not sub-components of existing elements. You cannot, for example, add other systems as users of the ATM system—this would be an architectural change. Similarly, you cannot add another communications channel, such as a Bluetooth connection between the Person’s cell phone and the ATM system. This, too, would be an architecture change.
Mapping Refinement
As we noted back in Chapter 3, many design decisions are made in the process of creating the mapping between the process model and the architecture pattern. For this reason, it is important to apply the concept of refinement here as well so that the reasoning behind these design decisions remains valid.
Figure 19-7 shows the mapping for the ATM example at an early stage in the architecture in which the ATM system has no sub-structure.
Figure 19-7. Process-Pattern Mapping before Refinement
Figure 19-8 shows the mapping after the ATM System structure has been refined to incorporate the sub-structure of ATM Machines and an ATM Server. Note that although some of the original ATM System activities have just been assigned to either the ATM Machine or ATM Server, others have been decomposed. This decomposition requires interaction among the sub-activities, and thus communications between the ATM Machine and ATM server.
Figure 19-8. Process-Pattern Mapping after Refinement
A key element of this decomposition is that, from the perspective of the Customer and the Bank System, nothing has changed. Their interactions remain the same despite the decomposition of the ATM System. This is the core requirement of mapping refinement.
Reference Architecture as the Entire Solution
There are two possible approaches for leveraging reference architectures in defining solutions. One occurs when the reference architecture encompasses the entire solution. The other, considered in the following section, occurs when the reference architecture represents only a fragment of the solution.
When the reference architecture encompasses the entire solution, the solution can be developed from the reference architecture exclusively through the process of refinement. Consider the reference architecture for a query that was considered back in Chapter 4. Let’s look at building a query that finds books based upon the author’s name.
Process Model Refinement
Refining the query reference architecture process model into the specific book query is relatively straightforward (Figure 19-9). Most of the refinement consists of making the terminology specific to the type of query.
Figure 19-9. Refining the Query Process Model
Perhaps the most interesting aspect of the process refinement is detailing the query result. Figure 19-10 shows the refined result.
Figure 19-10. Refining the Query Result
Architecture Pattern Refinement
Refining the architecture pattern for the query again adds detail (see Figure 19-11). The browsers being supported are Internet Explorer version 8 and Firefox. The application server will be a WebSphere server. The service will be called the Book Search Service, and the back-end system will be an Oracle database.
Figure 19-11. Refining the Architecture Pattern
Mapping Refinement
The mapping refinement for the query example is straightforward as well. The reference architecture mapping is shown in Figure 19-12 (this is actually a copy of Figure 4-4, repeated here for convenience).
Figure 19-12. Reference Architecture Mapping
The refined mapping is shown in Figure 19-13.
Figure 19-13. Solution Mapping after Refinement
This particular example is notable for the lack of change in taking the reference architecture and building the solution. This is actually good news—it means that there are no significant design decisions to be made in applying the reference architecture. All the decision-making has already been done. From a project perspective, the result is lower cost and faster time to complete. From an enterprise perspective, the result is consistent implementation of a well-considered design across multiple projects. There is a worthwhile return on the up-front investment in creating the reference architecture.
Reference Architecture as a Solution Fragment
Another scenario for applying reference architectures arises when the reference architecture is used as a fragment of the solution. Let’s take a look at refining the membership validation service in this manner.
Architecture Pattern Refinement
Figure 19-14 shows a possible refinement of the Membership Validation Service. The proposed refinement uses a single ActiveMatrix composite that contains two components: a Mediation Flow used for routing and a BusinessWorks process to access the local databases.
Figure 19-14. Membership Validation Service after Applying Reference Architectures
This refinement employs a number of reference architectures from earlier chapters. The Validate Membership Service Interface, provided by the mediation flow, has been promoted twice using two different transports. This is a refinement of the Straight-Wire Mapping pattern’s transport mapping use case from Chapter 14. The promoted services provide appropriate policy enforcement points for access control policies (Chapter 13).
Using the mediation flow as a router is a refinement of the Routing pattern, also from Chapter 14. Using BusinessWorks to access the local database is a refinement of the ActiveMatrix-initiated Direct Interaction via non-ActiveMatrix-supported protocols using BusinessWorks initiating the interaction (Chapter 15). The direct access of the partner system is an instance of the Direct Interaction via ActiveMatrix-Supported Protocols from the same chapter.
Inserting the refined structure of the service into the initial architecture pattern yields the refined architecture pattern of Figure 19-15. This is a strict refinement of the original pattern: There are no new design elements or communications channels. Note that this architecture can be readily extended to accommodate other back-end systems: The mediation flow can be easily modified to route to additional systems either by direct interaction or using adapters.
Figure 19-15. Refined Membership Validation Architecture Pattern
Mapping Refinement
The mapping provided in the original architecture was generic with respect to the back-end systems. With the refinement of the service structure, it is now necessary to be specific about the mapping details in each of the cases. Figure 19-16 shows the mapping when the back-end system is the local database. Here the database access component (BusinessWorks) has an interface that is identical to the overall service, and the transformation of the request into a database query takes place within this component.
Figure 19-16. Refined Mapping—Local Database Variant
Figure 19-17 shows the mapping when the back-end system is the partner system. It has a SOAP over HTTP interface of its own, and the transformation and invocation activities are carried out by the Mediation component.
Figure 19-17. Refined Mapping—Partner Variant
Summary
A solution architecture defines the structure and organization of a solution. It presents the same three views as any architecture: process models, architecture pattern, and process-pattern mappings.
A lot of detail has to be added to the solution architecture to get the complete solution. To maintain the validity of the reasoning that went into defining the architecture, implementation has to be conducted through a process of refinement. Refinement adds detail without altering structure. This is accomplished by adding sub-structure to activities in the process model and participants in the architecture pattern. These refinements require refinement of the mappings as well.
Reference architectures can be employed in the creation of solutions in two ways. When the reference architecture encompasses the entire scope of the solution, the solution can be constructed from the reference architecture entirely through the process of refinement. When the reference architecture encompasses only a fragment of the solution, refinement of the reference architecture yields a fragment of the solution.
Most of the reference architectures presented in this book are intended to be used as fragments of a solution. The Membership Validation Service example in this chapter contains a number of examples of this type of reference architecture utilization.