Service Oriented Solution Modeling and Variation Propagation Analysis Based on Architectural Building Blocks

Introduction

Service Oriented Architecture (SOA) has been widely acknowledged as a powerful model that opens a new cost-effective way of engineering software systems, by dynamically integrating and composing existing components into new business processes (Zhang, Zhang et al., 2007). Business applications designed and developed using the SOA technology are called SOA solutions or services solutions.

However, the actual application practice of SOA is not always successful. To date, most of SOA practices are conducted in an ad hoc manner and mainly based upon solution architects’ personal experiences. This is obviously neither practical nor efficient. Among others, one major reason is the lack of a systematic engineering methodology and an integrated design tool.

Unified Modeling Language (UML) mechanism (Arlow and7 Neustadt 2005), including Rational Unified Process (RUP) and Rational tools, has been extensively used to help software engineers design and develop enterprise-scale application systems in a uniform way. However, UML tools were designed for building generic software systems. Thus, they do not provide normative guidance and system-level support for building SOA solutions.

From industry practice, layered architectural models have been widely adopted by SOA practitioners to build SOA solutions. A typical example is IBM’s Service-Oriented Solution Stack (S3), which defines a conceptual view of a service-oriented architecture in the solutioning context (Arsanjani, Zhang et al., 2007). As shown in Figure 1, nine layers are identified, organized into a two-dimensional architecture with five horizontal layers and four vertical layers. The horizontal dimension (Operational System layer, Services Component layer, Service layer, Business Process layer, and Solution Consumer layer) implements functional requirements, and the vertical dimension (Integration layer, Data Architecture layer, Quality of Service (QoS) layer, and Governance layer) provides system-support facilities and enablement.

Figure 1.

SOA solution stack model

However, S3 alone is too coarse grained to be advisory for enterprise-level SOA solution design and development. It only provides high-level guidance for developers to design an SOA solution, i.e., in nine layers. To provide a uniform mechanism for building configurable and reusable SOA solutions on top of S3, we introduced a concept of Architectural Building Block (ABB) as the fundamental unit of an SOA solution (Zhang, Zhang et al., 2008). An ABB is a conceptual component that encapsulates internal states and functions and can be configured, extended, and instantiated. Each layer in S3 is comprised of multiple ABBs, which collaborate to carry out all expected activities. Based on industry experience, we recommended a collection of fine-grained ABB templates for each of the nine layers in S3 (Zhang, Zhang et al., 2008; Zhang and7 Zhang 2009; Zhang and7 Zhang, 2009; Zhang and7 Zhang, 2009).

Considering the adaptive feature of business scenarios, each project may have to configure and customize ABB templates to apt to proprietary requirements and constraints. Some ABBs, however, bear some inter-relationships between them. If an ABB is changed, related ABBs should be changed as well. Take our template for the Solution Consumer layer shown in Figure 2 as an example. A predefined 1:1 relationship exists between the Consumer ABB and the Presentation View ABB. If a project configures a Consumer ABB instance, a Presentation View ABB instance should be created accordingly.

Figure 2.

Solution consumer layer ABBs