Primitives And Design Patterns for Top-Down SOA Implementations

03/30/09

Primitives and Design Patterns for Top-Down SOA ImplementationsMichael zur MuehlenStevens Institute of TechnologyHoboken NJ

1

03/30/09

Engineering vs. Architecture

‣ If you show the same circuit diagram to two electrical engineers they will be able to understand the diagram because- The symbols are drawn the same

way everywhere- The symbols have a well-defined

meaning (semantics)- All electrical engineers are

trained on the same set of symbols

2

03/30/09 3

Moreover: They are likely to build functionally equivalent

and interoperableimplementations

03/30/09

Enterprise Architecture

‣Many Frameworks

‣Many Views

‣Many Techniques- UML, IDEF, BPMN, RAD, EPC, PowerPoint and many, many others...

4

<<TupleType>>

Activities::PerformerRuleConstrainsActivityOverlap

<<TupleType>>

ResourceFlows::PersonnelTypePartOfSystem

<<TupleType>>Activities::ActivityWholeConsumingPartOfActivity

<<TupleType>>ResourceFlows::SkillPartOfPersonnelType

<<TupleType>>

Rules::RuleGuidanceOfActivityValidUnitorCondition

<<TupleType>>Activities::ActivityWholeProducingPartOfActivity

<<powertype>>

ResourceFlows::ArchitectureOverviewAndPurpose

<<type>>Locations::IntentionallyConstructedInd

ividual

<<TupleType>>Goals::VisionsRealizedByDesiredEff

ect

<<powertype>>ResourceFlows::Information

<<TupleType>>ResourceFlows::PerformerLocationOverlap

<<type>>ResourceFlows::Resource

<<powertype>>ResourceFlows::ResourceType

<<powertype>>

Activities::ConsumingPartOfActivity

<<powertype>>ResourceFlows::PerformerType

<<TupleType>>Activities::ActivityPerformedByPerformer

<<TupleType>>Activities::ActivityResultsInEffect

<<TupleType>>ResourceFlows::MaterielPartOfSystem

<<type>>ResourceFlows::EffectObject

<<TupleType>>Capability::CapabilityPerformerManifestation

<<TupleType>>Goals::EffectPartOfCapability

<<TupleType>>Locations::FacilityPartOfSite

<<powertype>>Measures::Measure Type

<<powertype>>

ResourceFlows::DomainInformation

<<powertype>>

ResourceFlows::ServiceDescription

<<TupleType>>

InformationAndData::DescribedBy

<<TupleType>>ResourceFlows::DataPartOfInformation

<<TupleType>>Services::ServiceEnablesAccessTo

<<powertype>>

Activities::ProducingPartOfActivity

<<TupleType>>

Activities::ActivityChangesEffectObject

<<IndividualType>>

Locations::GeoPoliticalExtent

<<TupleType>>

ResourceFlows::nameTypeInstance

<<IndividualType>>ResourceFlows::IndividualResou

rce

<<IndividualType>>Locations::PlanerSurface

<<TupleType>>Activities::PerformerSupportingActivity

<<TupleType>>Activities::ActivityPerformerOverlap

<<IndividualType>>ResourceFlows::IndividualPerfo

rmer

<<type>>ResourceFlows::Means

<<type>>ResourceFlows::Performer

<<powertype>>

ResourceFlows::Service<<powertype>>

ResourceFlows::PersonnelTyp

e

<<TupleType>>

Activities::ActivityResourceOverlap

<<powertype>>ResourceFlows::NameType

<<powertype>>TrainingSkillEducation::Skill

<<TupleType>>

Activities::ActivityConditionOverlap

<<TupleType>>Rules::RuleConstrainsActivity

<<type>>Measures::NeedsSatisfaction

Measure

<<powertype>>ResourceFlows::Materiel

<<TupleType>>InformationAndData::namedBy

<<powertype>>ResourceFlows::Data

<<IndividualType>>ResourceFlows::Organizatio

n

<<TupleType>>Activities::ActivityPartOCapability

<<powertype>>ResourceFlows::System

<<TupleType>>

Goals::DesiredEffectDirectsActivity

<<IndividualType>>Locations::Location

<<type>>Services::ServicePort

<<TupleType>>Services::PortPartOfPerformer

<<type>>Measures::Maintainability

Measure

<<IndividualType>>Locations::Site

<<type>>Measures::Organizational

Measure

<<IndividualType>>Locations::Facility

<<TupleType>>Project::GoalsRealizedByProject

<<TupleType>>

InformationAndData::tuple

<<NameType>>ResourceFlows::Address

<<TupleType>>InformationAndData::DataAss

ociation

<<powerType>>Services::ServiceChannel

<<type>>Measures::PhysicalMe

asure

<<type>>Measures::SpatialMea

sure

<<type>>Measures::Performanc

eMeasure

<<type>>Measures::AccuracyPr

ecision

<<type>>Measures::RateThroug

hput

<<type>>Measures::Capacity

<<type>>

Measures::Dependability

<<type>>

Measures::Trustworthiness

<<type>>

Measures::Reliability

<<type>>

Measures::Security

<<type>>Measures::ServiceLev

el

<<type>>Measures::Adaptability

Measure

<<type>>Measures::Interoperabi

lity

<<type>>Measures::EffectsMea

sure

<<type>>Measures::Cost

<<IndividualType>>Locations::GeoFeature

<<IndividualType>>Locations::Surface

<<IndividualType>>Locations::Line

<<IndividualType>>Locations::Point

<<IndividualType>>Locations::Country

<<IndividualType>>

Locations::RegionOfCountry

<<IndividualType>>Locations::SolidVolum

e

<<IndividualType>>

Locations::Installation

<<TupleType>>Locations::SitePartOfIn

stallation

<<IndividualType>>Locations::RealPropert

y

<<IndividualType>>Goals::Vision

<<IndividualType>>Goals::Goal

<<powertype>>ResourceFlows::Organ

izationType

<<type>>Services::Port

<<IndividualType>>Measures::Measure

<<powerType>>Rules::TechnicalStandard

<<type>>InformationAndData::Thing

<<type>>

Measures::Timeliness

<<NameType>>

ResourceFlows::Name

<<powerType>>Activities::ServiceFunction

<<individualType>>Rules::FunctionalStandard

<<TupleType>>

Services::InterfaceType

<<individualType>>Rules::Guidance

<<type>>

Capability::Capability

<<powertype>>Activities::Activity

<<individualType>>Rules::SecurityAttributes

Group

<<individualType>>Rules::Constraint

<<powerType>>Rules::ServicePolicy

<<IndividualType>>Project::Project

<<powertype>>

Activities::Condition

<<individualType>>Rules::Rule

<<individualType>>Rules::Agreement

<<powertype>>

Goals::DesiredEffect

<<individualType>>Rules::Standard

<<powerType>>

Activities::Event

<<powertype>>

Project::Plan

1

0..*

place2Type

place1Type

nameType

place2Type

nameInstance

place1Type

wholeInformation

place2Type

dataPart

place2Type

place1Type

place1Type

place2Type

2

pointOnLine

place2Typeplace1Type

place2Type

place1Type

place2Type

1..*

place1Type

place1Typeplace2Type

0..1

place1Type

nameType

place4Type

place2TypeassociateOne

place3Typerelationship

place1TypeassociateTwo

place1Type

thingDescribed

place2Type

tuplePlace2

place1Type

tuplePlace1

place1Typeplace2Type

place1Type

place2Type

place2Typedescription

place2Type

place2Type

place1Type

place1Type

thingBeingDescribed

place2Type

place1Type

place2Type place1Type

place1Type

place2Type

place1Type

place2Type

place1Type

place2Type

place2Type

place1Type

place1Type

place1Type

place1Type

place1Type

place2Type0..*

place3Type

place2Type

place3Type

place1Type

place2Type

place2Type

place2Type

place1Type

place1Type

place2Type

place1Type

place2Type

place1Typeplace3Type

place2Type

0..*

03/30/09

Modeling Freedom

5

03/30/09

Design Primitives and Patterns

6

03/30/09

Low- and High-Level Patterns

7

Patterns are composed of Primitives!

03/30/09

The Nescafé Process

8

03/30/09

The Espresso Machine Process

9

03/30/09

The Starbucks Process

10

03/30/09

Systematic Composition

11

03/30/09

3-Level Hierarchy: Milestones

12

03/30/09

3-Level Hierarchy: Collaboration

13

03/30/09

3-Level Hierarchy: Procedures

14

03/30/09

Hohpe’s SOA on a Napkin

15

Source: Gregor Hohpe (2009)

03/30/09

Hohpe’s SOA on a Napkin

16

Source: Gregor Hohpe (2009)

Object-oriented Dev’mnt

Process Modeling

Protocol Design

Declarative Programming Object-Document Mapping

03/30/09

Define Your Vocabulary First

17

Define Capabilities

What is the architecture supposed to achieve?

Items:• Objectives• Features• Services

Define Resources

Which data/resources will be consumed or produced?

Items:•Nouns

Define Activities

Which processes/activities will provide the capabilities?

Items:• Verbs

Define Performers

Who/What will be involved?

Items:• Roles• Systems• Actors

03/30/09

How the Vocabulary Relates

18

Resource Resources may be Performers

Activity(Process)

realized through

Sub-Activity(Activity)

In/Out

Decom

p.

Resource

Define Capabilities

Define Resources

Define Activities

Define Performers

Capability

Perfo

rms

Performer

03/30/09

Summary

‣Minimize Diagram Types: Fewer primitives to learn‣Standardize Patterns: Unified use of modeling language‣Define Vocabulary first: Lexicon ties model types together

‣A realistic design standard for modelers, architects, and tool vendors

19

03/30/09

For More Information

20

Available on DKO:

Email: Michael.zurMuehlen@stevens.edu