Service-Oriented Analysis and Design
a.k.a. SOA Decision Modeling (SOAD)

Project Overview

Perspectives on Web Services discusses service modeling challenges and architectural decisions required during Web services design. However, it does not cover the more general conceptual SOA design issues around service composition and Enterprise Service Bus (ESB). Therefore, Olaf Zimmermann initiated the SOAD project. The motivation for this project is to give SOA practitioners concrete, tangible service modeling and realization advice in a comprehensive and consumable way. Olaf coined the term Service-Oriented Analysis and Design for a submission to the OOPSLA 2004 Onward! track, which in June 2004 evolved into a popular and frequently cited article on IBM developerWorks. While the original paper touched upon some solution elements, its main intent was to stimulate a discussion and call for method engineering activities. Several SOAD solutions have been developed since then; for instance, SOMA from IBM defines three service identification, service specification and service realization steps and suggests techniques for them.

The objective of SOA Decision Modeling is to complement existing SOAD methods such as SOMA with techniques, architectural knowledge, and innovative tool support required during service realization. Our two central metaphors are architectural patterns, a popular concept to describe proven solutions to recurring problems, and, less known, architectural decisions. Architectural decisions so far have mainly been used to document designs; in SOAD, we extend their usage context and make them an integral element of the design process. We are in the process of creating a reusable SOA Decision Model, which we structure according to Model-Driven Architecture (MDA) principles. Capturing and structuring the decision knowledge is a challenge; SOA practitioners are confronted with hundreds, if not thousands of decisions once the SOA project leaves "Planet PowerPoint": integration and workflow pattern selection, language and protocol choices, security and transactionality, etc. While patterns capture the available conceptual solutions, our architectural decisions model the corresponding problems, along with detailed information about decision drivers (a.k.a. forces, quality attributes) and the best practices that apply. All this is fed by our industry project experience - we took a rear view mirror on our own SOA projects, mining to dos and lessons learned. At present, we have collected about 300 decisions, only few of which are already published. Please have a look at our presentations and papers to get a feel.

This project is conducted by the Business Integration Technologies Team (BIT) at the IBM Zurich Research Lab, receiving academic guidance from Frank Leymann, IAAS, Stuttgart University and Jana Koehler, the manager of the ZRL BIT Team. The project also has executive support from several service lines of business at IBM. We have discussed our approach with many members of the patterns community such as Gregor Hohpe, Markus Voelter and Uwe Zdun. Grady Booch reviewed the project in November 2007.

ECOWS Keynote

Olaf Zimmermann's ECOWS 2007 keynote motivates why existing general purpose and servied modeling methods do not cover software service engineering sufficiently, gives first examples of recurring architectural decisions, and introduces Architectural Decision Modeling as our solution to the problems perceived on our case studies.

Download the Presentation

Reusable Architectural Decision Models for Enterprise Application Development

Features decision making framework, domain meta model, decision identification-making-enforcement steps, SOA decision space overview.

Abstract: In enterprise application development and other software construction projects, a critical success factor is to make sound architectural decisions. Text templates and tool support for capturing architectural decisions exist, but have failed to reach broad adoption so far. One of the inhibitors we perceived on large-scale industry projects is that architectural decision capturing is regarded as a retrospective and therefore unwelcome documentation task which does not provide any benefit during the original design work. A major problem of such a retrospective approach is that the decision rationale is not available to decision makers when they identify, make, and enforce decisions. Often a large, possibly distributed, community of decision makers is involved in these three steps. In this paper, we propose a new conceptual framework for proactive decision identification, decision maker collaboration, and decision enforcement. Based on a meta model capturing reuse and collaboration aspects explicitly, our framework instantiates decision models from requirements models and reusable decision templates. These templates capture knowledge gained on other projects employ ing the same architectural style. As an exemplary application of these concepts to service-oriented architecture shows, reusable architectural decision models can speed up the decision identification and improve the quality of the decision making. Reusable architectural decision models can also simplify the exchange of architecture design rationale within and between project teams, and expose decision out come as model transformation parameters in model-driven software development.

Article and Presentation

Service-Oriented Architecture and Business Process Choreography in an Order Management Scenario

Features an SOA and BPEL case study from the telecommunications that went into production in early 2005. Rationale, architecture overview, lessons learned.

Abstract: Effective and affordable business-to-business process integration is a key success factor in the telecommunications industry. A large telecommunication wholesaler, supplying its services to more than 150 different service retailers, enhanced the process integration capabilities of its core order management system through wide­spread use of SOA, business process choreography and Web services concepts. This core order management system processes 120 different complex order types. On this project, challenging requirements such as complexity of business process models and multi-channel accessibility turned out to be true proof points for the applied SOA concepts, tools, and runtime environments. To implement an automated and secured business-to-business Web services channel and to introduce a process choreography layer into a large existing application were two of the key requirements that had to be addressed. The solution complies with the Web Services Interoperability Basic Profile 1.0 and makes use of executable business process models defined in the Business Process Execution Language (BPEL). This paper discusses the rationale behind the decision for SOA, process choreography, and Web services, and gives an overview of the BPEL-centric process choreography architecture. Furthermore, it features lessons learned and best practices identified during design, implementation, and rollout of the solution.

Read the Article

Second Generation Web Services-Oriented Architecture in Production in the Finance Industry

Features a Web services case study (SOAP, WSDL) that went into production in early 2003. Rationale, architecture overview, lessons learned.

Abstract: Effective and affordable business process integration is a key concern in the finance industry. A large German joint-use centre, supplying services to 237 individual savings banks, enhanced the integration capabilities of its core banking system, consisting of more than 500 complex functions, through aggressive use of Web services. Advanced requirements such as heterogeneous client environment, sub-second response times, 300% traffic growth, and interface complexity did challenge today's Web services implementations. To achieve true interoperability between Microsoft (MS) Office/.NET and Java, and to implement more than 500 Web service providers in a short time frame were two of the most important issues that had to be solved. The current, second release of this solution complies with the Web Services Interoperability (WS-I) Basic Profile 1.0. Leveraging the Basic Profile reduced the development and testing efforts significantly. This report discusses the rationale behind the decision for Web services, and gives an architectural overview of the integration approach. Furthermore, it features the lessons learned and best practices identified during the design, implementation and rollout of the solution.

Read the Article

RESTful Web Services vs. Big Web Services: Making the Right Architectural Decision

Features a conceptual and technology comparison of REST and WS-* (SOAP/WSDL/...) using architectural decisions as comparison metric.

Abstract: Recent technology trends in the Web Services (WS) domain indicate that a solution eliminating the presumed complexity of the WS-* standards may be in sight: advocates of REpresentational State Transfer (REST) have come to believe that their ideas explaining why the World Wide Web works are just as applicable to solve enterprise application integration problems and to simplify the plumbing required to build service-oriented architectures. In this paper we objectify the WS-* vs. REST debate by giving a quantitative technical comparison based on architectural principles and decisions. We show that the two approaches differ in the number of architectural decisions that must be made and in the number of available alternatives. This discrepancy between freedom-from-choice and freedom-of-choice explains the complexity difference perceived. However, we also show that there are significant differences in the consequences of certain decisions in terms of resulting development and maintenance costs. Our comparison helps technical decision makers to assess the two integration styles and technologies more objectively and select the one that best fits their needs: REST is well suited for basic, ad hoc integration scenarios, WS-* is more flexible and addresses advanced quality of service requirements commonly occurring in enterprise computing.

Download the Article

Architectural Decisions and Patterns for Transactional Workflows in SOA

Features three conceptual patterns (TransactionBridge, TransactionIslands, StratifiedStilts), layer-specific primitives for system transaction management in process-enabled, workflow-based SOAs. Maps the conceptual abstractions to BPEL engine(s) and SCA technology.

Abstract: An important architectural style for constructing enterprise applications is to use transactional workflows in SOA. In this setting, workflow activities invoke distributed services in a coordinated manner, using transaction context-propagating messages, coordination protocols, and compensation logic. Designing such transactional workflows is a time-consuming and error-prone task requiring deep subject matter expertise. Aiming to alleviate this problem, we introduce a new analysis and design method that (a) identifies recurring architectural decisions in analysis-level process models, (b) models alternatives for these decisions as reusable, platform-independent patterns and primitives, and (c) maps the patterns and primitives into technology- and platform-specific settings. Our method accelerates the identification of decisions, empowers process modelers to make informed decisions, and automates the enforcement of the decisions in deployment artifacts; tool support is available. We demonstrate value and feasibility of our method in an industry case study.

Article and Presentation

Combining Pattern Languages and Architectural Decision Models into a Comprehensive and Comprehensible Design Method

Features 38 architectural decisions for broker-based and/or process-enabled SOA and discusses the synergetic relation between patterns and decisions.

Abstract: When constructing software systems, software architects must identify and evaluate many competing design options and document the rationale behind any selections made. Two supporting concepts are pattern languages and architectural decision models. Unfortunately, both concepts only provide partial support: Extensive upfront education is needed for practitioners to be in command of the full pattern literature relevant in their field; retrospective architectural decision modeling is viewed as a painful extra responsibility without immediate gains. In this paper, we combine pattern languages and reusable architectural decision models into a design method that is both comprehensive and comprehensible. Our design method identifies the required decisions in requirements models systematically, gives domain-specific pattern selection advice, and provides traceability from platform-independent patterns to platform-specific decisions. We validate our approach by applying it to enterprise applications as an exemplary application genre and a SOA case study from the finance industry.

Article and Presentation

Architectural Decision Models as Micro-Methodology for Service-Oriented Analysis and Design

Features the role of architectural decisions in model-driven SOA construction: position statements, required model transformations, research agenda.

Abstract: During the construction of service-oriented architectures, service modelers concern themselves with the characteristics of good services and how such services can be designed. For instance, they look for advice regarding interface granularity and criteria to assess whether existing software assets are fit for reuse in service-oriented environments. There are no straightforward answers to such questions – service identification, specification and realization techniques are required. Service identification and specification are well covered by existing methodologies; for service realization, architectural decision models can be leveraged. At present, the construction of architectural decision models is an education- and labor-intensive undertaking; if such models exist at all, they often are isolated from other artifacts. In this paper, we propose a new engineering approach to service modeling that leverages reusable architectural decision models as its central service realization concept. We outline a multi­level decision tree and position it as a prescriptive service realization methodology for three engagement types observed in practice. The benefits of service engineering with reusable architectural decision models are semi-automatic decision identification in analysis models, improved decision making quality, and better decision enforcement and risk mitigation capabilities

Download the Full Article and the Short Positioning Paper

Tutorial: SOA Principles and Patters, Core Web Services Technologies, SOAD Overview

Our OOPSLA and ECOWS tutorials introduce SOA as an architectural style that manifests itself through top-level architectural patterns such as Enterprise Service Bus (ESB), Service Composiiton (a.k.a. Business Process Choreography), and Service Registry. Modules 2 and 3 present core Web services technologies such as SOAP and WSDL by example. Module 4 presents the original 26 decisions from "Perspectives on Web Services", as well as several more new decision making examples.

Download Tutorial Handouts and Sample Code

Web 2.0 Tool Support for Collaborative Architectural Decision Engineering

Nelly Schuster developed Architectural Decision Knowledge Wiki, the application wiki we use to make the SOAD content available to practitioners, in her diploma thesis, Hochschule der Medien, Stuttgart, Germany, March 2007. The tool is available at the IBM alphaWorks Emerging Technologies website.

Download the tool from IBM alphaWorks or Nelly's thesis here

Other Papers Featuring SOAD Concepts and Decision Content

Several more papers about service modeling appear under Papers and Talks. A complete and up-to-date list of all papers originating from the SOAD project can be found on Olaf's external staff page at the Institute for Architecture of Application Systems (IAAS), Stuttgart University. More papers from the Business Integration Technologies (BIT) team are available at the BIT group page at the IBM Zurich Research Lab.