Primitives And Design Patterns for Top-Down SOA Implementations

Primitives and Design Patterns for Top-Down SOA Implementations Michael zur Muehlen Stevens Institute of Technology Hoboken 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

Moreover: They are likely to build functionally equivalent and interoperable implementations 03/30/09 3

4 03/30/09 - UML, IDEF, BPMN, RAD, EPC, PowerPoint and many, many others... ‣ Many Techniques ‣ Many Views <<type>> <<TupleType>> C apability::Capability C apability::CapabilityP erformerManifestation place1Type place1Type <<pow ertype>> A ctivities::Condition <<TupleType>> place1Type Goals::E ffectP artOfCapabi lity place1Type <<Tupl eType>> A ctivities::A ctivityR esultsInE ffect place2Type place2Type pl ace2Type <<TupleType>> <<TupleType>> <<TupleType>> <<Indi vidual Type>> A ctivities::A ctivityC ondi tionOverlap A ctivities::A ctivityP artOC apability <<TupleType>> <<pow ertype>> Goal s::V isi onsR ealizedB yD esiredE ff Goals::V ision place3Type place2Type place1Type Goals::D esiredE ffectD irectsA ctivity Goals::D esi redE ffect ect place2Type pl ace1Type place2Type 0..1 place1Type <<pow ertype>> A ctivities::A cti vity place1Type place3Type place2Type place1Type place1Type <<IndividualType>> Goals::Goal <<TupleType>> A ctiviti es::A cti vityP erformerOverl ap place1Type <<pow erType>> <<TupleType>> <<pow erType>> 1..* A ctiviti es::E vent A ctivi ties::A ctivi tyC hangesE ffectObject A ctiviti es::S erviceFunction <<pow ertype>> P roject::P lan <<TupleType>> <<Tupl eType>> <<TupleType>> <<TupleType>> A ctivities::P erformerS upportingA ctivity A ctivities::A ctivityP erformedB yP erformer A ctivities::A ctivityW holeC onsumingP artOfA ctivity A ctivities::A ctivityW holeP roduci ngP artOfA ctivi ty <<TupleType>> <<Indi vidual Type>> P roject::GoalsR ealizedB yP roj ect P roject::P roject pl ace1Type pl ace2Type place2Type place2Type <<TupleType>> <<pow ertype>> <<pow ertype>> R ules::R uleGuidanceOfA ctivityV al idUnitorC ondition A ctivities::P roducingP artOfA ctivity A ctivities::ConsumingP artOfA ctivi ty <<individualType>> R ules::Guidance pl ace2Type <<TupleType>> R ules::R uleConstrainsA ctivi ty pl ace1Type <<individualType>> place1Type <<i ndivi dualType>> pl ace3Type <<TupleType>> R ules::S ecurityA ttributes 0..* place2Type R ules::R ule <<pow ertype>> A ctivities::A ctivityR esourceOverlap Group pl ace2Type 1 Measures::Measure Type 0..* <<TupleType>> <<IndividualType>> A ctivi ties::P erformerRuleC onstrainsA ctivityOverlap Measures::Measure place4Type <<individual Type>> <<individualType>> <<individualType>> <<type>> <<type>> <<type>> <<type>> <<type>> <<type>> <<type>> R ules::S tandard R ules::A greement R ules::C onstraint Measures::P hysi cal Me Measures::E ffectsMea Measures::P erformanc Measures::NeedsS atisfacti on Measures::Maintainability Measures::A daptability Measures::Organizational asure sure eMeasure Measure Measure Measure Measure <<individualType>> <<pow erType>> <<pow erType>> R ules::Functi onalS tandard R ules::TechnicalS tandard R ul es::S erviceP oli cy <<type>> <<type>> <<type>> <<type>> <<type>> <<type>> Measures::S patialMea Measures::A ccuracyP r Measures::RateThroug Measures::Capacity Measures::Interoperabi Measures::Cost sure eci si on hput lity <<type>> <<type>> <<type>> Measures::Timeliness Measures::Dependabil i Measures::S ervi ceLev ty el <<type>> R esourceFl ow s::E ffectObject place2Type <<type>> <<type>> <<type>> place1Type Measures::Trustw orthi Measures::Rel iability Measures::S ecurity ness place2Type <<type>> R esourceFl ow s::R esource pl ace2Type 0..* place2Type <<type>> Locations::IntentionallyC onstructedInd ividual <<IndividualType>> <<pow ertype>> <<type>> <<type>> R esourceFl ow s::Individual R esou R esourceFlow s::R esourceType R esourceFlow s::Means R esourceFlow s::P erformer place1Type rce place2Type place1Type <<IndividualType>> Locations::Location <<TupleType>> <<Tupl eType>> place2Type R esourceFlow s::P erformerLocationOverlap S ervi ces::P ortP artOfP erformer <<type>> InformationA ndD ata::Thing place1Type tupl eP lace1 <<IndividualType>> <<Indivi dualType>> <<IndividualType>> <<IndividualType>> <<Indi vidual Type>> <<type>> <<IndividualType>> <<IndividualType>> <<pow ertype>> Locations::GeoFeature Locations::S oli dV olum Locations::S urface Locati ons::Line Locations::P oint <<pow ertype>> <<pow ertype>> <<pow ertype>> associateOne place2Type <<TupleType>> S ervi ces::P ort <<TupleType>> R esourceFlow s::IndividualP erfo Locations::GeoP oliti calE xtent place2Type R esourceFlow s::Materi el e R esourceFlow s::P erformerType R esourceFlow s::Information R esourceFlow s::D ata InformationA ndD ata::D ataA ss InformationA ndD ata::tuple pointOnLine rmer place1Type associateTwo ociation 2 place2Type place1Type place2Type place3Type relationship tupl eP lace2 w holeInformation dataP art <<TupleType>> place2Type R esourceFlow s::D ataP artOfInformation <<TupleType>> pl ace1Type <<TupleType>> <<TupleType>> <<IndividualType>> <<Indivi dualType>> <<IndividualType>> <<IndividualType>> <<Indi vidual Type>> InformationA ndD ata::D escribedB y S ervices::S erviceE nablesA ccessTo R esourceFlow s::MaterielP artOfS ystem description Locations::P l anerS urface Locati ons::RealP ropert Locations::Country R esourceFlow s::Organizatio thingD escribed Locations::Instal lati on pl ace2Type place1Type y n place1Type <<Tupl eType>> pl ace1Type InformationA ndD ata::namedB y <<pow ertype>> <<pow ertype>> <<type>> <<pow ertype>> <<pow ertype>> <<pow ertype>> <<pow ertype>> <<pow ertype>> <<NameType>> place1Type R esourceFlow s::S ervice R esourceFl ow s::Organ S ervices::S ervi ceP ort R esourceFlow s::S ystem R esourceFlow s::P ersonnelTyp <<Indivi dualType>> <<TupleType>> <<Indi vidual Type>> R esourceFlow s::S erviceD escription R esourceFlow s::D omainInformation R esourceFlow s::A rchitectureOverview A ndP urpose R esourceFlow s::N ame <<IndividualType>> izationType e Locations::Facility Locati ons::S iteP artOfIn Locations::S i te nameType Locations::RegionOfCo thingB ei ngDescribed stallation untry <<TupleType>> place2Type pl ace2Type R esourceFlow s::nameTypeInstance nameInstance nameType place1Type pl ace2Type place2Type place1Type <<NameType>> place1Type R esourceFl ow s::A ddress <<Tupl eType>> <<TupleType>> <<pow ertype>> Locations::Facil ityP artOfS ite R esourceFlow s::P ersonnelTypeP artOfS ystem R esourceFlow s::N ameType place1Type <<TupleType>> place1Type S ervices::InterfaceType <<Tupl eType>> R esourceFlow s::S ki llP artOfP ersonnelType <<pow erType>> S ervi ces::S erviceC hannel place2Type <<pow ertype>> TrainingS killE ducation::S kill pl ace1Type ‣ Many Frameworks Enterprise Architecture

Modeling Freedom 03/30/09 5

Design Primitives and Patterns 6 03/30/09

Low- and High-Level Patterns Patterns are composed of Primitives! 7 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 03/30/09 11

3-Level Hierarchy: Milestones 03/30/09 12

3-Level Hierarchy: Collaboration 03/30/09 13

3-Level Hierarchy: Procedures 03/30/09 14

Hohpe’s SOA on a Napkin Source: Gregor Hohpe (2009) 03/30/09 15

Hohpe’s SOA on a Napkin Object- Protocol Process oriented Design Modeling Dev’mnt Declarative Object-Document Mapping Programming Source: Gregor Hohpe (2009) 03/30/09 16

Define Your Vocabulary First What is the Which data/ Who/What will Which architecture resources will be involved? processes/ supposed to be consumed activities will achieve? or produced? provide the capabilities? Define Define Define Define Resources Activities Performers Capabilities Items: Items: • Objectives Items: Items: • Roles • Features • Verbs • Systems •Nouns • Services • Actors 03/30/09 17

How the Vocabulary Relates Define Define Define Define Capabilities Resources Activities Performers Activity Capability realized through (Process) Decomp. Performs Sub-Activity Resource In/Out (Activity) Resource Performer Resources may be Performers 03/30/09 18

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 Available on DKO: Email: Michael.zurMuehlen@stevens.edu 03/30/09 20

Primitives And Design Patterns for Top-Down SOA Implementations

0 comments

Notes on slide 1

1 Favorite