making the right architectural decisions with soa decision ... · architecture and design patterns...

Business Integration Technologies

© 2008 IBM Corporation

Making the Right Architectural Decisions with SOA Decision Modeling and Architectural Decision Knowledge Wiki

May 19, 2008 - USI Lugano

Olaf ZimmermannExecutive IT ArchitectIBM Zurich Research Lab

Guest

pautasso

Text Box

Guest Lecture at the Software Architecture and Design Course at the Faculty of Informatics, University of Lugano (USI), Switzerland


© 2008 IBM Corporation2 Zurich Research Laboratory

Session Description and Objectives

Software architects view systems under construction from multiple viewpoints such as the 4+1 logical, development, physical, process, and scenario viewpoints used in the Unified Process; methods and tools for software architects typically center on such structural viewpoints. The capturing of architectural decision rationale and knowledge, however, is another essential viewpoint, which has been neglected by software architecture research so far; existing tools and templates for this viewpoint do not meet the wants and needs of practicing architects.In this lecture, we present two large-scale SOA industry projects to motivate the need for architectural decision modeling. We introduce a domain meta model for architectural decision capturing and a reusable SOA decision model harvested from full lifecycle projects since 2001. We also investigate selected decisions such as the selection of message exchange patterns and configuration of system transaction boundaries in detail.We also demonstrate how to capture architectural decisions and alternatives in Architectural Decision Knowledge Wiki, a Web 2.0 collaboration system and application wiki supporting decision maker collaboration over the Web. Domain meta model, reusable SOA decision model and application wiki jointly support real-world usage scenarios such as project team education, architecture design method support, and facilitation of technical quality assurance reviews and SOA governance.



Architectural Decision Making with Architectural Decision Knowledge WikiModule 1: Motivating Case Study and Modeling Overview

Olaf ZimmermannNelly Schuster



Agenda

1. Case studyBroker-based integration of core banking application components

2. Existing workArchitectural patterns and decision capturing

3. ArchPad and RADM for SOA walkthroughRefinement stages

Reusable decision content

4. Tool support: Architectural Knowledge Decision Wiki

5. Conclusions and outlook



Agenda









Java Client

Web Application

.NET Client Browser Office

Web Services Adapter Layer

JavaTM API (Dynamic Interface)

Java Backend Connectors (IBM WebSphere MQ, CICS®)

Access Layer

Business Function

WSDL

generate

generateDatabase(IBM DB2®)

Repository

generate

Documentation

(pSeries)

(zSeries)

Platform independent

IBM CICS

IBM WebSphere®

Case Study: Core Banking SOA with Web Services

Dyn

amic

Inte

rfac

e

SOAPSOAP SOAP

Zimmermann, O.; Milinski, M.; Craes, M.; Oellermann, F.: Second Generation Web Services-Oriented Architecture in Production in the Finance Industry, OOPSLA Conference Companion, 2004



Some of the Required Architecture Design Activities

Selection of top-level integration pattern– BROKER from “Patterns of Software Architecture” (POSA) is an obvious choice

[POSA] suggests six steps to implement the pattern:“(1) Define an object model. (2) Decide which type of component interoperability the system should offer, binary or Interface Description Language (IDL). (3) Specify the APIs the broker component provides for collaborating with clients and servers. (4) Use proxy objects to hide implementation details from clients and servers. (5) Design the broker component (6) Develop IDL compilers.”

Step (5) has nine sub steps: “(5.1) On-the-wire protocol, (5.2) Local broker, (5.3) Direct communication variant, (5.4) (Un)marshalling, (5.5) Message buffers, (5.6) Directory service, (5.7) Name service, (5.8) Dynamic method invocation, (5.9) The case in which something fails”.

This is helpful, but which (design) patterns are suited to implement the steps? What about the required technology choices? Product selections?

Buschmann F., Meunier R., Rohnert H., Som-merlad P., and Stal M., Pattern-Oriented Soft-ware Architecture – a System of Patterns. Wiley, 1996



Agenda









Architecture and Design Patterns

In the last couple of years, patterns have become part of the mainstream of OO software development– Single pattern is one solution to a

particular, recurring problem – However, “real problems" are more

complex

Different kinds of patterns:– Design patterns (GoF)– Software architecture patterns

(POSA, POSA2)– Analysis patterns (Fowler, Hay)– Organizational patterns (Coplien)– Pedagogical patterns (PPP)– Many others

Uwe Zdun, Markus Voelter, Michael Kircher - Remoting Patterns.15

Remoting Patterns

• Numerous projects • use, • extend, • integrate, • customize, and • build

distributed object middleware• Goals:

• illustrate the general, recurring architecture of successful distributed object middleware

• illustrate more concrete design and implementation strategies

• Book: published in Wiley‘sPattern Series in 2004

“Each pattern is a three-part rule, which expresses a relation between a certain context, a certain

system of forces which occurs repeatedly in that context, and a certain software configuration which

allows these forces to resolve themselves.” (Coplien summary of Alexander’s definition)

This slide: Zdun U., Voelter M., Kircher M., Remoting Patterns, JAX 2004 Tutorial



Decision Capturing Templates and Ontologies

IBM Global Services Method a.k.a. Unified Method Framework (UMF)– Defines a work product (artifact) “ARC 100 Architectural Decisions”

Tyree and Akerman derived own decision capturing template from an instance of an ARC 100 work product for e-business architectures– Issue, decision, status, group, assumptions, constraints, positions, argument– Implications, related decisions, related artifacts, related principles, notes

Kruchten et al. define decision and dependency types– State model, decision types, decision dependencies

Retrospective decision capturing for documentation purposes (no reuse)!

J. Tyree, A. Akerman, Architecture Decisions: Demystifying Architecture, IEEE Software, vol. 22, no. 2, 2005

Kruchten, P., Lago, P., van Vliet, H.: Building up and Reasoning about Architectural Knowledge. In: Hofmeister, C., Crnkovic, I., Reussner, R. (eds.) QoSA 2006. LNCS, vol. 4214, pp. 39–47. Springer, Heidelberg (2006)



Agenda



3. ArchPad and RADM for SOA walkthroughRefinement stagesReusable decision content





Retrospective vs. Proactive Decision Capturing/ModelingDocumenting architectural decisions should be state of the practice

– “For IBM GTS, ARC 100 is most important UMF work product besides Operational Model”– Real-world constraints for retrospective decision capturing: motivation, budget, tools?

Using pre-populated AD models in an active, guiding role is a novel approach– Give reusable advice regarding decisions still required on project, as opposed to rationale

behind decisions already made

Software Product

Product Documentation

Design Models and Code on Early Adoption Project

Design Models and Code onMainstream Projects

ARC 100 Work Product ARC 100 Work ProductsPredefined ARC 100

(Required Decisions)Adds Recommendations and

Decision Outcome Have to Capture Delta Only



IGS Method/UMF ARC 100 template extended into a UML meta model which facilitates reuse and collaboration.

Quality attributes & NFRs:– decision drivers and “best

practices” recommendation (AD)

– pros and cons of alternatives (AA)

– justification (ADOutcome)

Design model and process alignment:

– scope attribute (AD)– phase attribute (AD)– responsibleRole attribute (AD)

Decision lifecycle:– status and owner

(ADOutcome)– takenWhen (ADOutcome)

1) NFRs, quality attributes

3) Rationale

2) Advantages and disadvantages of available design options



Content: Sample SOA Decision (AD, ADAlternative)

Decision drivers: reliability needs, systems

management capabilities, availability of provider

Scope: Operation (Layer 3 + Layer 6)

AD: Msg-01, Message Exchange Pattern (Conceptual/Technology Level)

Do consumer and provider communicate synchronously or asynchronously?

Background reading: Hohpe/Woolf “Enterprise Integration Patterns”

Phase: Macro DesignRole: Integration Architect

Recommendation: Do not follow the MOM hype – decoupling in time is just one of several dimensions of loose coupling. The equation (NOT RM => NOT SOA) does not hold true.

Service Model WSDL

Alternative 1:Request-Reply

SOAP/HTTP

Simple to manage, but no guaranteed

delivery, so *might* have to

deal with undelivered and/or

duplicate messages

Alternative 2:One Way over Reliable

Transport

JMS or WS-RM

Consumer and provider up times can differ;

guaranteed delivery (once and only once) when

using persistent messages. Must manage

dead letter queue. SOAP Engine Selection

MOM/JMSProvider Selection

HTTP Server Selection

Alternative 3:Pseudo-

Asynchronous

Combination of Alternative 1 on Layer

3 (service), Alternative 2 on Layer

6 (transport)

Same as Alternative 1, but guaranteed

delivery

Decision Identification Decision EnforcementDecision Making

MOM:Message-Oriented Middleware

JMS: Java MessagingService

WS: Web Services

RM:Reliable Messaging



300+ Decisions in Reusable ADM (RADM) for SOA

In and Out Parameter Granularity

Transaction Management

Session Management

SOAP Engine Selection

Transaction Attributes

Patterns



ArchPad

1.0: Requirements Analysis incl. Quality Attributes (a.k.a. Decision Drivers, Forces)

2.2: Architectural Patterns (e.g., POSA, PoEAA, SOA)

3.1: Technology Decisions(Subsystem Architects, Development Leads)

4.1: Vendor Asset Decisions(Developers and Platform

Specialists)

1.1: Executive Decisions(Decided by External Stakeholders or

To Dos for Overall Team Leads)

3.2: Design Patterns(e.g., Gang of Four,

Core J2EE, remoting, messaging)

4.2: Implementation andTest Patterns,

Known Uses of Patternsfrom Previous Stages

1.2: Business Patterns (e.g., Analysis Patterns,

Industry Reference Models)

Start

RADM-E RADM-C RADM-T RADM-A

2.1: Conceptual Decisions(Lead Architects,

Subsystem Architects)

Stage 1: “Forming” Stage 2: “Storming” Stage 3: “Norming” Stage 4: “Performing”

Method: Architectual Patterns and Decisions (ArchPad)



ArchPad and Reusable ADM (RADM) for SOA…

… complement existing design methods– Integration into process via phase and role

attributes

– Decision model as an additional viewpoint on software architecture, scope attribute

– Decision driver attribute and QOCr diagrams as a decision making support technique

… and complete them with service realization/construction advice– Several hundred SOA related decisions

captured in actionable form• Best practices exchange via

recommendations attribute– Based on ArchPad domain meta model

Micro “P”:Plugs into ex. work

“N”:Plugs into ex. work

“T” & “C”: Focus area

RADM for SOA



Agenda









Tool Support: Architectural Decision Knowledge Wiki



Presentation:Web UI (Wiki)

Persistence:Rel. DB

Components of Architectural Decision Knowledge Wiki

Domain:OO-PHP

Content Repository1

Outcome Lifecycle

4

Depen-dencies

3

Collabo-ration

5

Import/ Export

2

Schuster N., Zimmermann O., Pautasso C., ADkwik: Web 2.0 Collaboration System for Architectural Decision Engineering. In: Proc. of the Nineteenth International Conference on Software Engineering & Knowledge Engineering (SEKE 2007)



Agenda









Module 1 Summary – ArchPad (Method), RADM for SOA(Content), Architectural Decision Knowledge Wiki (Tool)

Method: Decision model as domain-specific guide through the stages, architecture and design patterns describe alternatives in detail– Architectural decisions are conceptual alternatives

– Design and technology patterns come in on subsequent stages

Content: Decision models rather than text templates – Four refinement stages: executive, conceptual, technology, and asset decisions

– Pre-population of RADM from experience gained on earlier SOA projects

Tool: Innovative application wiki for decision knowledge sharing and collaboration– Wiki frontend for model-driven domain layer and relational database

– 50+ use cases: CRUDS on domain model elements, ARC 100 report generation



Exercise 1: Reflection on Today’s Decision Making Practices

1. Which AD hurt your head most on your last project?

2. What did you do to resolve it?

3. Which forces influenced your decision making?

4. Where did you look for help?

5. How did you document your decision?

6. Were your lessons learned specific to your project, or would you say they are applicable to other client project situations?

7. If so, how did you share them with the community?

Time: 5 minutes



Sample Solutions to Exercise 1: Reflection on Today’s Decision Making Practices

1. Which AD hurt your head most on your last project?Probably too many to mention… was it a project-specific or a recurring one? How about service granularity, system transaction boundaries in process-enabled SOA, SOAP vs. REST?

2. What did you do to resolve it?Gut feel, architecture workshops, run PoC, consult general-purpose method (with SOA plugin)

3. Which forces influenced your decision making?Previous experience, NFRs, general software quality attributes such as performance, scalability

4. Where did you look for help?Personal network, online articles, official knowledge repositories

5. How did you document your decision?Meeting minutes, component/operational model, ARC 100 (standard/own template)

6. Were your lessons learned specific to your project, or would you say they are applicable to other client project situations?

All sample decisions mentioned above recur on most if not all SOA projects.

7. If so, how did you share them with your community (practitioner network)?No time (had to move on to next project), AoT conference template (PowerPoint)



Architectural Decision Making with Architectural Decision Knowledge WikiModule 2: Guided Tour through AD Knowledge Wiki Tooling




Module 2: Agenda

1. User Interface (UI) and architecture overviewKey use casesModeling vs. text templates, proactive vs. reactive

2. Key conceptsDecision identificationDecision drivers, decision scopingDesign model and process alignmentMacro and micro processKnowledge reuse and enforcement

3. Usage scenarios and project adoptions

4. Exercises

5. Discussion



Motivation and Use Cases for Architectural Decision (AD) Knowledge Wiki (“ARC 100++”)

Meet regulatory compliance requirements– E.g., maturity models

Provide collaboration features– In geographically distributed teams

Facilitate reuse– Of already gained knowledge

Other required features:– Import and export– Searching and filtering– Dependency management– ARC 100 report generation



Conceptual Component Model for AD Knowledge Wiki

Domain Layer

Decision Workflow Component

Dependency Management Component

Versioning and Reporting Component

Persistence Layer

Collaboration Component

Application W

iki Infrastructure, AP

I

Presentation Layer

Decision-WorkflowView

Dependency-Management-

View

AdView

Collaboration-View

NavigationView

ErrorHandlingComponent

LoggingComponent

SecurityComponent

AdData-Source-

Component

Server-Component

RDBMS Import/Export Component

Import/Export-View

Content Repository

Best of both worlds – QEDWiki engine and layered enterprise application– One page/commend/relational database table per domain model element



Decision Model Element in AD Knowledge Wiki UI



ARC 100 Report

IGS Method/UMF “ARC 100++” formatting

Scope, phase, role annotation

Explicit alternatives

Model support for ordering, filtering, searching

Dependencies preserved as hyperlinks

Editorial (lifecycle) information available



Searching and Filtering Capabilities

Helps with decision space customization:– By role, phase, scope

– By engagement type

– By subject area/tag



Relationship Editor

Key feature of a decision model tool (in contrast to free form or text templates)– Here: Architectural decision and architecture alternative level



Domain Model Reference

Architectural Decision (AD) and ADAlternative– Rich attribute set incl. status information

ADTopic and ADProject– For organization of knowledge

Refer to AdKwik/UsersGuide/AdkwikConcepts



Decision Outcome Instances

The “Investigate Decision” tab in the user interface merely tells you what you have to worry about, not what the decision actually is– This is the job of the “Make Decision” tab, listing decision outcome instances

– A default can be defined

An AD outcome (a.k.a. decision instance) can have different states:– open: This means, a description and several alternatives are captured, but no

decision was yet made.

– decided: Now an alternative was chosen.

– confirmed: The responsible person approved the decision.

– rejected: The made decision was rejected due to some reasons.



Other Concepts in Architectural Decision Knowledge Wiki

Decision topics

Decision identification (background info)

Design model and process alignment– Explicit scope, phase, and role attributes of AD

Decision drivers captured as first-class attribute– Notion of “quality attributes” in software architecture research (e.g., SEI)

– Term “forces” used in pattern community

Refer to online Users Guide and Samples for more information



Module 2 Summary –Architectural Decision Knowledge Wiki

In this module you have learned about:

The use cases for Architectural Decision Knowledge Wiki – Create, read, update, and delete ADs, ADAlternatives, ADTopics

– Search for ADs by scope, by role, by phase, by keyword tag

– Import and export of decisions, possibly filtered

– ARC 100 report generation

– Relationship editor

The AD capturing domain model– Decision drivers

– Alternatives with pros and cons

– Recommendations

– Decision background vs. decision outcome instances



Exercise 2: Domain Model for Single AD

Work with SoadSample1 in Architectural Decision Knowledge Wiki: “GUI orientation and decision capturing template“– Login in and create a copy of the sample project in one of the TeamXX projects

that have already been created for you: http://<HOST-IP>/ibmmsk/qed/wiki_web_app/page/show?pg=TeamXX

• Open the project overview page and click on “Decision Modeling” > “Import Decisions”

• Select SoadSample1 as import source (under “Import from AD project: ”)• Select your TeamXX project as import sink (under “Import into AD project: ”)

– Go to the Samples page (located under “Help” > “Users Guide” and then “Samples”). Follow the instructions and answer the questions to exercise 1-1:http://<HOST-IP>/ibmmsk/qed/wiki_web_app/page/show?pg=AdKwik%2FUsersGuide%2FSamples

(hint: you might want to open a second browser window or tab)

Time for this exercise: 15 minutes



Sample Solutions to Exercise 2

Sample solutions and answers are available online – Appearing in Users Guide of Architectural Decision Knowledge Wiki:

http://<HOST-IP>/ibmmsk/qed/wiki_web_app/page/show?pg=AdKwik%2FUsersGuide%2FSolutionsToExercises



Architectural Decision Making with Architectural Decision Knowledge WikiModule 3: SOA Decisions (SOAD)




Motivating Case Study: Multi-Channel Order Management SOA in the Telecommunications Industry

Functional domain– Order entry management– Two business processes:

new customer, relocation– Main SOA drivers: deeper

automation grade, share services between domains

SOA infrastructure– Web and EJB container,

business process engine, backend adapters

– Recurring architectural decisions: • Protocol choices• Transactionality• Security policies• Interface granularity

BusinessProcessLayer

ChannelController

BusinessServices

Screen1 Screen2Presen-tation

Browser Channel Web Services Channel

ApplicationServices

Business Objects

CoreSystems

BusinessObjects

CoreSystem 1

BS1 BSn

AS1 ASn

. . . . . . other

? WS Façades

Activity Stub 1 Activity Stub n?

BSF1 BSF n

Client Client

ValueObject

ValueObjectShort Running

ProcessActivities

WSDLWSDL

WSDLWSDL

ActivityImplementation 1

ActivityImplementation n

CoreSystem n

Business Process Engine

Message format? Transport protocol?Which EAI/ESB to use?

Internal and/or external ESB topology?

Authentication and encryption required?Transactionality? Compensation?Session and state management?

Is business process executable?Which BPM/workflow engine to use?

In which topology configuration?



Types of Recurring Service Design Issues

1. Selection and adoption of application and integration patterns

2. Technology choices – protocols, containers, operating systems, etc.

3. Commercial or open source asset selection and configuration, e.g., for high availability and performance

Hundreds, if not thousands, of questions have to be answered:– Many decisions already made before project starts

• By client – previous projects, legacy systems• By other parties – software vendor, IT consultants

– Many forces that influence/drive the decision making, often contradictory– Numerous complex dependencies between the options– Never enough time to analyze all options in detail– Literature is overwhelming



QOCr Diagram for Message Granularity Decision

C: Functional requirements (domain model), capabilities of BPEL, SOAP, WSDL, XML processors (verbosity), interoperability, network topology, number of deployment artifacts

and generated code structure, strong vs. weak typing philosophy.

Scope:Service Operation

AD: Msg-03, InMessageGranularity (Conceptual Level)

Q: How many message parts should be defined in the service contract?How deep should the part elements be structured?

No patterns available yet.

O1: Dot pattern

Single scalar parameter

Easy to process for SOAP/XML

engines, much work for

programmer

Phase: Macro Design

R: All alternatives have their place, depending on the concrete decision drivers. Base decision on layer and service type. Avoid overly deep nesting of data structures

unless you want to stress test the XML processing. Minimize message verbosity.

Service Model

Service Type

WSDL, XSD Contracts

O2:Bar pattern

Single complex parameter

Deep structure and exotic types can

cause interoperability

issues.

O3:Dotted line pattern

Multiple scalar parameters

Handled by all common engines, some programmer

convenience.Enterprise Data Model

Business Granularity

O4:Comb pattern

Multiple complex parameters

Combination of options 2 and 3,

biggest overhead for processing

engines.

OutMessageGranularity

OperationToService

Grouping

XML Profiling

WDSL, XSD Editor

Selection

Role: Service Modeler



Application Architecture Infrastructure Arch. Example

Decision Model Organized by Layers and Levels

Business Requirements

Decisions

Conceptual Level

Technology Level

Vendor AssetLevel

Executive Decisions

Physical VP:Conceptual Decisions

Logical VP:Conceptual Decisions

Physical VP: Technology Decisions

Logical VP:Technology Decisions

Physical VP: Vendor/Asset

Decisions

Logical VP: Vendor/Asset

Decisions

e.g. MessageExchangePattern

e.g. TransportProtocol

e.g. DataPowerConfiguration

Component Layer

Service Layer

Process Layer

Integration Layer

QoS

Layer

Consumer Layer

Resource Layer

Component Layer

Service Layer

Process Layer

Integration Layer

QoS

Layer

Consumer Layer

Resource Layer

Component Layer

Service Layer

Process Layer

Integration Layer

QoS

Layer

Consumer Layer

Resource Layer VP – Viewpoint

Business Executive Level



Conceptual Level

On this platform-independent level:– Selection of integration patterns

– Security and management concepts

– Decisions required to create conceptual operational model

Dependencies:– Between topics on same level

– Refinement dependencies to corresponding decisions on the technology level

See Appendix for overview on SSS layers



Conceptual Transactionality Decision

Drivers: Resource Protection Needs, Data Currency,

Performance

Activity/Operation

AD Srd-05: Invocation Transactionality (Conceptual)

Should process and invoked services run in a single or in multiple system transactions?

See ICSOC 2007 paper by Zimmermann et al

Alternative 1: Transaction Islands

Do not share Txcontext

Best performance, loose coupling, but

no full ACID protection for

resources.

Macro Design Process Modeler

Recommendation: Use Transaction Islands as default, Stratified Stilts for long running, distributed processes.

Injection into model transformation or BPEL code in WID is possible.

WBM or RSAProcess

Model

Workflow pattern and

engine selection

WID BPEL

Process Model

Compensation Patterns

Alternative 2: Transaction Bridge

Share Tx context

Best resource protection, but

large, long running Tx tightly coupling

activities and services.

Alternative 3:Stratified Stilts

Use asynchronous messaging and

suspend Tx

Supports, loose coupling best, but

no full ACID protection.

SCA qualifiers, BPEL server

configuration, WS-AT usage



Technology Level

On this platform-specific level:– Selection of implementation technologies

implementing the platform-independent patterns and concepts (not yet products!)

– Protocols, algorithms, formats, etc.

– Decisions required to create specified operational model


– Refinement dependencies to corresponding decisions on the vendor/asset level




Conceptual and Technology Decisions about Encryption

Drivers: Confidentiality needs, performance, number of

intermediariesScope: Operation

AD: Msg-03, Encryption Layer and Technology (Technology Level)

Where and how should service messages be encrypted?

See book by Weerawarana et al: “Web Services Platform Architecture”

Phase: Macro DesignRole: Security Specialist

Recommendation: Stick to SSL/TLS unless message-level security required due to business requirements; use HW accelerator when deciding for WSSE

Service Model

Security Architecture Directions

WSDL, XSD

Alternative 1:Transport-Layer

Encryption

SSL/TLS (HTTPS)

Well adopted on the Web, but no

end-to-end security.

Alternative 2:Message-Layer

Encryption

XML digital signatures WSSE

Allows end-to-end security across

intermediaries, but is expensive.

WSSE Engine Selection(SW, HW)

Engine Configuration

(HTTP, WSSE)

SSL Provider Selection(SW, HW)



Vendor/Asset Level

On this second platform-specific level:– Selection and configuration of products

and open source assets supporting the selected implementation technologies

– Decisions required to create physical operational model


– Decisions correspond to deployment artifacts e.g. in IBM DataPower and WebSphere ESB




Questions, Options, Criteria for Clustering Decision

Drivers: Availability needs, budget, logical service design

(session affinity)Scope: Node

AD: Wesb-01 WebSphereClustering (Vendor Asset Level)

Should WebSphere Application Server be deployed in a standalone or in a high availability configuration?

See WebSphere Info Center and platform patterns documents

Phase: Macro DesignRole: Infrastructure Architect

Recommendation: Stick to Alternative 1 unless business requirements and NFRs force you to use Alternative 2. Design services to be able to run in clustered configuration

(e.g., store only serializable Java objects and only a few KB in HTTP session object)

NFRs,Component

Model

Runtime Topology Directions

Operational Model

Alternative 1:Single Server

No node manager

Easy to manage, but service consumers can not be served

when WAS instance or server HW are

down. Server failure leads to loss of session data.

Alternative 2:Cluster

Enable node manager, have multiple nodes that can take over from each

other

Higher availability from consumers perspective,

hot/cold session takeover required. Systems

management needs.

Systems Management

Decisions

Cluster Configuration

(WAS)

Storage Decisions

(HA?)



Module 3 Summary – SOAD and RADM for SOA Content

In this module, you have learned about:

The organizational principles in SOAD– MDA levels: Conceptual, Technology, Vendor Asset– SSS layers, e.g. process (L4), service (L3), service component (L2),

integration (L6)

Key decisions required during SOA design, and alternatives available– Message exchange patterns and formats, transport protocol– QoS characteristics such as reliability, transactionality, security

SOA-specific decision drivers (NFRs, quality attributes) and related best practices recommendations

The relationship between SOAD and IGS Method/UMF work products such as component model and operational model



Exercise 3 a): Content Organization Part 1: Levels

Work with SoadSample2 in Architectural Decision Knowledge Wiki: “Refinement levels and decision dependencies“– Log in and create a copy of the sample project under in of the TeamXX projects that

have already been created for you: http://<HOST-IP>/ibmmsk/qed/wiki_web_app/page/show?pg=TeamXX



(delete any existing decision tree when prompted)– Go to the Samples page (located under “Help” > “Users Guide” and then “Samples”).

Follow the instructions and answer the questions to exercise 2-1:http://<HOST-IP>/ibmmsk/qed/wiki_web_app/page/show?pg=AdKwik%2FUsersGuide%2FSamples

(hint: you might want to open a second browser window or tab)




Exercise 3 b): Content Organization Part 2: Layers

Work with SoadSample3 in Architectural Decision Knowledge Wiki: “Architectural layers and decision scoping“– Create a copy of the sample project under one of the TeamXX projects that have

already been created for you: http://<HOST-IP>/ibmmsk/qed/wiki_web_app/page/show?pg=TeamXX



(delete any existing decision tree when prompted)– Go to the Samples page (located under “Help” > “Users Guide” and then “Samples”).

Follow the instructions and answer the questions to exercise 3-1:http://<HOST-IP>/ibmmsk/qed/wiki_web_app/page/show?pg=AdKwik%2FUsersGuide%2FSamples




Exercise 3 c): Levels, Layers, and Content Creation(Optional/After Lab)

1. Download the WWW 2008 paper “RESTful Web Services vs. Big Web Services: Making the Right Architectural Decision”

– Available at http://soadecisions.org/soad.htm#www

2. Review Tables 1, 2, and 3 in that paper:– Which levels are covered?– How many architectural decisions are discussed?– How do the decisions map to ADTopics defined in the Reusable ADM for SOA (RADM

for SOA) that we introduced in this module (hint: have a look at the screen shots on pages 44, 46, and 48)?

3. (optional) Create your own project in Architectural Knowledge Decision Wiki and capture the ADs and ADAlternatives discussed in the paper.

Time: 30 minutes (steps 1 and 2)



Sample Solutions to Exercise 3 c)

1. Download the WWW 2008 paper “RESTful Web Services vs. Big Web Services: Making the Right Architectural Decision”

– Available at http://soadecisions.org/soad.htm#www

2. Review Tables 1, 2, and 3 in that paper:– Which levels are covered?

• The Conceptual and the Technology Level. The Vendor Asset Level is mentioned, not included due to space constraints. As the theme of the paper is technology comparison, there is no Business Executive Level, but coverage of architectural principles (“decision drivers” in SOAD).

– How many architectural decisions are discussed?• 9 conceptual decisions, 10 technology decisions (plus 3 principles).

– How do the decisions map to ADTopics defined in the Reusable ADM for SOA (RADM for SOA) that we introduced in this module (hint: have a look at the screen shots on pages 53, 55, and 57)?• Conceptual Level: Layer3ServiceRealizationDecisions (and sub-topics, not shown)• Technology Level: Layer3WebServiceBindingDecisions, Layer3RestfulIntegrationDecisions

3. (optional) Create your own project in Architectural Knowledge Decision Wiki and capture the ADs and ADAlternatives discussed in the paper.

– Sample solution provided in SOAD master (IBM internal for the time being)



Architectural Decision Making with Architectural Decision Knowledge WikiModule 4: Case Studies




Introduction to Case Study #1: Customer Enquiry Processing in the Insurance Industry

Let us assume the project is in solution outline phase and draft versions of the following artifacts exist already:– System context diagram– Analysis-level Business-Process Model (BPM)– Business rules and Non-Functional Requirements (NFRs)– Initial architecture overview diagram or high-level component model

Let us further assume that you just joined the SOA project team:– For your orientation, draft work products can be provided– Please review Section 2, “Architecturally Significant Requirements and First

Design Ideas”

Please time box the project orientation activities: 15 minutes



Introduction to Case Study #2 (optional/alternative to #1): Telecommunications Order Management

Let us assume the project has completed the solution outline phase and these artifacts exist:– System context diagram– Analysis-level Business-Process Model (BPM)– Business rules and Non-Functional Requirements (NFRs)– Initial architecture overview diagram or high-level component model

Let us further assume that you have been asked to review the solution:– For orientation, refer to OOPSLA 2005 practitioner report “Service-Oriented

Architecture and Business Process Choreography in an Order Management Scenario”, available from http://soadecisions.org/art.htm#casestudy1

Please time box the project/paper review activities: 30 minutes



Exercise 4 a): Decision Identification

Take the lead/integration architect role on one of the case study projects and identify 5-10 required or made architectural decisions in the work product(s) you just studied:– High-level component model (hint: look for architectural patterns)– Business rules and NFRs (hint: find justifications for pattern selections) – Analysis-level BPM (hint: look for candidate services) – System context diagram (hint: look for project scoping decisions)

Hint: The project documentation might not be complete and consistent… feel free to ask questions; the instructor will be happy to act as project stakeholder. It is also ok to bring in your enterprise application development and SOA experience at this point ☺

Time for this exercise: 15 mins



Exercise 4 b): Decision Making

Log in and work with the SOAD content available in SoadSample3 to locate reusable advice regarding the following decisions:• Would you introduce a “service composition (workflow) layer”?• If yes, why? If not, what alternative architecture do you propose?• Which “service composition language” seems to be most appropriate?

What are the decision drivers, alternatives and their pros and cons?• Which SCA implementation qualifier must be selected to implement the

conceptual pattern “TransactionBridge”, which is an alternative for the decision “Msg-05 InvocationTransactionalityPattern” (hint: locate Crd-05 “ServiceProviderTransactionalityST” and find related decisions)? Where can more information about this rather complex design issue be found?

… if you disagree with any of the advice given, please update the wiki!

Time for this exercise: 30 mins



Exercise 4 c): Decision Enforcement (Optional/After Lab)

Create your own project and capture all decisions identified in Exercise 4 a) and made/reviewed in Exercise 4 b)– Work with the UsersGuide and the FAQs if struggling with user interface

– Do not forget to document your decision justifications and assumptions!

– Have a look at the provided DecisionCapturingAdvice and BackgroundReading

– Generate ARC 100 report when done

Time for this exercise: – 5 mins (when using RADM for SOA and accepting recommendations)

– 30 mins plus (when capturing decisions and outcome from scratch)



Sample Solution to Exercises 4 a) and b)

Exercise 4 a): Decision Identification– SoadSample3 in Architectural Decision Knowledge Wiki provides about 20 decisions, all of which

are required in both cases studies.

Exercise 4 b): Decision Making– Should a “service composition (workflow) layer” be introduced or not?

Yes. – If yes, why? If not, what alternative architecture do you propose?

The long-running nature of the process and the multi-actor coordination and process integrity requirements justify the introduction of such a layer.

– Which “service composition language” seems to be most appropriate? What are the decision drivers, alternatives and their pros and cons? BPEL, which is standards-based and tool supported. See Eadt-04 ServiceCompositionLanguagewhich is contained in ADTopic TechnologyLevel/EnterpriseApplicationDesignDecisions

– Which “SCA implementation qualifier” must be selected to implement the conceptual pattern “TransactionBridge”, which is an alternative for the decision “Msg-05 InvocationTransactionalityPattern” (hint: locate Crd-05 “ServiceProviderTransactionalityST” and find related decisions)? Follow dependency link from Msg-05 to Crd-05 and then Sca-06 “ImplementationQualifiers”. Transaction=global is the right qualifier. For justification, see Table 1 in this paper: http://soadecisions.org/soad.htm#icsoc



Sample Solution to Exercises 4 c) and More Information

Exercise 4 c): Decision Enforcement– No sample solution provided for the time being

The BackgroundReading/SoadPapers pages refer you to several other papers and presentations with more detailed knowledge:– E.g. “”Combining Architectural Decisions and Patterns into a Comprehensive

and Comprehensible Design Method”• http://soadecisions.org/soad.htm#wicsa

– E.g., “Architectural Decisions and Patterns for Transactional Workflows in SOA”• http://soadecisions.org/soad.htm#icsoc

– E.g., “RESTful Web Services vs. Big Web Services: Making the Right Architectural Decision”• http://soadecisions.org/soad.htm#www



Architectural Decision Making with Architectural Decision Knowledge Wiki

Summary

April 6, 2008TLE 2008 Olaf Zimmermann

Nelly Schuster



Summary

In this tutorial, you learned…– …. how important architectural capturing and sharing is

– … how decision topics, decisions, alternatives and decision instances can be modeled in Architectural Decision Knowledge Wiki

– … that a good share of the knowledge can be made reusable if application domain (EAD) and architectural style (SOA) are known (RADM for SOA, SOAD)

– … that the decision modeling concepts can help with architecture design in real cases



Thank You!

Questions?

Comments?

Input to ArchPad and SOA RADM?

“Perspectives on Web Services”, Springer-Verlag– Captures project experience 2001-2003, incl. 26 architectural decisions about Web

services design

– Foreword by Grady Booch

– Website also has case study reports and other referenced papers

http://www.soadecisions.orgolz(at)zurich.ibm.com



Architectural Decision Making with Architectural Decision Knowledge Wiki

Background InformationAppendices




Download Information

Architectural Decision Knowledge Wiki Version 1.0 (was: ADkwik)– http://www.alphaworks.ibm.com/tech/adkwik (IBM alphaWorks, public)

IBM Mashup Starter Kit, Version 1.0 on alphaWorks (contains QEDWiki)– http://www.alphaworks.ibm.com/tech/ibmmsk

Zend and DB2– See ADkwik installation guide and QEDWiki release information

Supported browsers (as of March 31, 2008):– Mozilla Firefox 2.0.0.13 (recommended)

– Internet Explorer 7.0.5730.11



References

More information is available from the following Web pages:– BIT group @ ZRL

• http://www.zurich.ibm.com/csc/bit (external)– SOA Decision Modeling Project

• http://www.soadecisions.org/soad.htm– Up-to-date publication list at

• http://www.iaas.uni-stuttgart.de/institut/extern/zimmermann/indexE.php



5+4 “layers” – not a strict layering scheme as for example in OSI networking:– Resource layer (1), service components (2), services layer (3), business process layer (4),

consumer layer (5)– Integration layer (6), QoS layer (7), information architecture layer (8), governance layer (9)– More information: http://www.ibm.com/developerworks/library/ar-archtemp/index.html

Appendix A: IBM SOA Solution Stack (SSS)



Appendix A: Layered SOA reference architecture and SOA decisions

Decision space organized by layers of a SOA reference architecture– IBM SOA Solution Stack by default [IBM SSS]– Other ones possible

Refinement dependencies from conceptual to technology to vendor asset level– Process layer: workflow concepts, BPEL

technology, IBM Process Server product asset– Same for integration layer: messaging, ESBs

Concepts

Technology

Assets

Processes

making the right architectural decisions with soa decision ... · architecture and design patterns...

Documents