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

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

Liang-Jie Zhang (Kingdee International Software Group CO., Ltd, Shenzen, China) and Jia Zhang (Carnegie Mellon University, Pittsburgh, PA, USA)
Copyright: © 2013 |Pages: 23
DOI: 10.4018/ijwsr.2013100102


In spite of the widely recognized benefits of applying Service Oriented Architecture (SOA) to design enterprise-scale software systems, its actual application practice is not always a success. One major reason is the lack of a systematic engineering process and tool supported by reusable architectural artifacts. Toward this ultimate goal, this paper proposes a new method of architectural building blocks (ABB)-based SOA solution design and it is applicable to any layered or tiered infrastructure. The authors present the modeling of solution-level architectural artifacts and their relationships, whose formalization enables event-based variation notification and propagation analysis. The goal is to provide architecture-level support for configuration and re-configuration of architectural artifacts based on industry practices. Their method also supports solution-level project variation management for the process of updating and maintaining architectural artifacts. The authors report a prototype tool that they have developed and describe how they extend the Unified Modeling Language (UML) mechanism to implement the system and enable solution-level enforcement as an example. The prototype has been applied in real projects as an SOA solution modeling tool.
Article Preview


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

Complete Article List

Search this Journal:
Open Access Articles
Volume 16: 4 Issues (2019): Forthcoming, Available for Pre-Order
Volume 15: 4 Issues (2018)
Volume 14: 4 Issues (2017)
Volume 13: 4 Issues (2016)
Volume 12: 4 Issues (2015)
Volume 11: 4 Issues (2014)
Volume 10: 4 Issues (2013)
Volume 9: 4 Issues (2012)
Volume 8: 4 Issues (2011)
Volume 7: 4 Issues (2010)
Volume 6: 4 Issues (2009)
Volume 5: 4 Issues (2008)
Volume 4: 4 Issues (2007)
Volume 3: 4 Issues (2006)
Volume 2: 4 Issues (2005)
Volume 1: 4 Issues (2004)
View Complete Journal Contents Listing