Juval Lowy IDesign SESSION CODE: ARC206 The Zen of Architecture ©2010 IDesign Inc. All rights reserved.

Juval LowyIDesignwww.idesign.net

SESSION CODE: ARC206

The Zen of Architecture

©2010 IDesign Inc. All rights reserved

About Juval LöwySoftware architect

Consults and trains on .NET architectureMicrosoft's Regional Director for the Silicon ValleyRecent book

Programming WCF Services (2010 O’Reilly)Participates in the .NET/WCF design reviewsPublishes at MSDN and other magazinesSpeaker at the major international development conferencesRecognized Software Legend by Microsoft Contact at www.idesign.net

The Zen of Architecture For the beginner architect, there are many optionsFor the Master architect, there are only a few

The MethodSimple and effective analysis and design technique

Mechanizes design decisions Focuses on the required run-time behavior

In 3-5 days System architecture comprising 40-60 diagramsDesign validation Vertical slice implementation and demonstration Stress testing

Removing design and technology as a risk

The MethodTime crunch essential for prioritizing, focusing and avoiding design gold-plating Eliminating analysis-paralysis

The MethodSharing and capturing across the team

Thought processTradeoffs and insightsUse cases analysis Operational assumptions Design decisions

Design and architecture survivalCommunicate between architects

The MethodThe Method is not a silver bullet

There are no silver bulletsDoes not take away

Creativity Responsibility to get the use cases rightLiability for getting it wrong

The method provide Good starting point Mechanical approach to design

The MethodAvoid "flow-chart" decomposition

Basing services on order of logical steps in use casesFunctional and time decompositionLeads to duplicating behaviors across services in increased numbers

Explosion of servicesIntricate relationships

Couples multiple services to data contractPromotes implementing uses cases in higher level terms thus difficult to reuse same behavior in another uses caseCouples services to order and current use cases

The MethodFunctional decomposition makes services too big or too smallFunctional decomposition means design added no value to sequence in use caseConsider performing anti-design effortThink about building a house functionally

The MethodDecompose based on volatility

Identify areas of potential changeCan be functional but not domain functional

Encapsulate in servicesMilestones based on integration not features

Implement behavior as interaction between volatile services or sub systemsVolatility is often not-self evident

Takes longer than functional

The MethodThe Method provides template for common areas to encapsulate

A good starting point Encapsulate classic volatile areas

Layers encapsulate top-down Services inside layers encapsulate sideways

The Method NotationsConventional common-place methodologies and tools are generations behind practices

UMLVSTSVS-Architect

Focus heavily on object relations and class hierarchyStuck in OO land

UML is too verbose

The Method NotationsUML has no way for graphically capturing

ServicesEndpoints and callbacks Assembly allocation Hosts and processesTransaction boundaries Identities Authentication and authorization boundaries Logical threads of execution and synchronizationVarious context maps

The Method NotationsThe Method relies on simple diagrams

Aspect or boundary is marked outSimplest symbols such as a box or a bar

Semantic of box or bar differs by context

Layered Approach Systems are typically designed in layers

Even simple systemsLayers layer encapsulationAll cross-layer entities are WCF services Service Service Service Service

.

.

.

.

Service Service Service Service

Service Service Service Service

Resource Resource

Layered Approach Cross-layer call to service promote and enable

Consistency Scalability Fault isolationSecurity Separation of presentation from logic

Windows Forms, WPF, ASP.NET, mobile Availability Throughput Responsiveness Synchronization

Typical Layers Client

AKA PresentationCan be a user or another systemCan be variety of client application technologies

Business Managers encapsulate sequence in use cases and workflows

Each manager is collection of related use cases Engines encapsulates business rulesManager may use zero or more enginesEngines may be shared between managers

Typical Layers Resource access

Encapsulate resource accessMay call resource stored in other servicesCan be shared across engines and managers

ResourcesPhysical resources

Utilities Common infrastructure to all services

ResourceAccess

Client Utilities

Security

AdminClient

Logging

Resource

Pub/Sub

.

.

.

Reports

Support

BusinessLogic

Resource1

Client A

Engine A

Resource AccessA

Client A Client D

Manager A

Client B

Engine B

Manager B

Client C

Engine C

Manager C

Engine D

Manager D

Resource2

Resource AccessB

Resource AccessC

Typical Layers A cohesive interaction between the manager, engines and resource access may constitute logical service to the world

Implementing a set of use cases Target of the vertical sliceHow you extend the system

Typical LayersIn between layers should pass only

Primitives Arrays of primitives Data contracts Arrays of data contracts

Logic behind data contracts should not cross layers 'Entities' could break encapsulationBehavior should be encapsulated not spread and shared

Resource Access

Client

Resources

BusinessLogic

Resource1

Client A

Service AEngine

Service ARes Access

Client D

Service AManager

Client B

Service BEngine

Service BManager

Client C

Service CEngine

Service CManager

Service DEngine

Service DManager

Resource2

Service BRes Access

Service CRes Access

Service DRes Access

Security

AdminClient

Logging

Pub/Sub

.

.

.

Reports

Support

Host

Architecture Validation Strive to have the minimal set of interacting services that satisfy use cases

Present and future use casesKnown and unknown use casesIterative factoring processMay affect use case as well

When all conceivable use cases are satisfied architecture is validatedStart with top distinct 4-6 use cases

No need for all use cases

Architecture Validation Change to use case means change to work flow

Manger implementation Not underlying services

Bulk of effort in system goes intoEngines Resource accessResource Clients and UIUtilities and infrastructure

Reuse effort across use casesAnd their inherit volatility

Open and Closed Architectures Open architecture

Can call anybody elseUp, down, sideways

Most flexibleLeast encapsulated

Little point in layers Potential for coupling

Open and Closed Architectures Closed architecture

Can call only into layer immediately underneathCannot call sideways to others

Coupled use cases Least flexible Most encapsulated Promotes decoupling

Open and Closed Architectures Semi closed/semi open

Can call any layer underneath but not up or sideways Trades encapsulation for flexibility and performance Use only in infrastructure or rarely maintained code

Always strive for closed architecture

Open and Closed Architectures Should reduce complexity and overhead in closed systemsCan always call utilities anywhereCan queue up calls sidewaysNeed to 'open up' a system typically indicates need for

Pub/sub systemQueuing

Does not actually violate design Managers can call engines and resource access

Not all steps in use case are volatileEngines and resource access are "thin" layer compared with resource or presentation

Open and Closed Architectures Sharing engines and resource access across managers is permitted

Engines are at orthogonal axis to managers at different planeStrategy pattern

Open and Closed Architectures Clients should not call multiple managers in single use case

Managers are coupled Functional decomposition

Other points Never queue calls to engines Do not queue calls to resource accessEngines do not publish eventsResource access do not publish eventsEngines do not subscribe to eventsEngines never call each other Resource access never call each other

Calls NotationsShould use interaction diagrams

Too time consuming and subverts 'crunch' Focus on architecture not detailed design

Superimpose use cases on services Black arrow for synchronous callsGray dashed arrow for queued call

Resource1

Service AEngine

Service ARes Access

Service AManager

Service BManager

Client A

Pub/Sub

Call Chains Once all core use cases are satisfied design is validated

Assembly Allocation Capture allocation of clients, services and utilities into assemblies In general

Client applications reside in application assembliesEverything else in class libraries

When not hosting in the WAS/AppFabric add host application assembliesDevelopers should not share assemblies

May or may not lead to 1:1 services to assembliesProvide early to build master

Developers hit the ground running

Client AApplication

Assembly (EXE)

Admin Client

Application Assembly (EXE)

Custom SecurityLibrary

Assembly (DLL)

Logbook ViewerApplication

Assembly (EXE)

LogbookLibrary

Assembly (DLL)

Pub/SubLibrary

Assembly (DLL)

ReportsApplication

Assembly (EXE)

Client DASP.NET

Assembly (DLL)

Client BApplication

Assembly (EXE)

Service A Manager Library

Assembly (DLL)

Service A Res Access

Library Assembly (DLL)

Service A EngineLibrary

Assembly (DLL)

Client CApplication

Assembly (EXE)

HostApplication

Assembly (EXE)

Service B Manager Library

Assembly (DLL)

Service B Res Access

Library Assembly (DLL)

Service B EngineLibrary

Assembly (DLL)

Service C Manager Library

Assembly (DLL)

Service C Res Access

Library Assembly (DLL)

Service C EngineLibrary

Assembly (DLL)

Service D Manager Library

Assembly (DLL)

Service D Res Access

Library Assembly (DLL)

Service D EngineLibrary

Assembly (DLL)

Service AllocationMark services in a boxIn general, these are always services

Managers Engines Resource accessLogbook

Optional servicesClients Every other class

Logbook Pub/Sub

Service AEngine

Service AManager

Client C

Service BEngine

Service BManager

Service CEngine

Service CManager

Service DEngine

Service DManager

Service ARes Access

Service BRes Access

Service CRes Access

Service DRes Access

Run-Time Processes AllocationAllocation of services to run-time processes

Who hosts whomBase on need for

Fault isolationSecurity isolation

Identities Authentication Authorization

Time-line isolationAdministration and Operations isolation

Run-Time Processes AllocationTypically

Layer boundary is process boundaryManagers do not share process Engines and resource access are in-proc to managers

No meaning on their own May be loaded into multiple manager processes

Group all assemblies that share process and enclose in a boxShow WAS/AppFabric processes as well

Client AApplication

Assembly (EXE)

Service A Manager Library

Assembly (DLL)

Service A Res Access

Library Assembly (DLL)

Service A EngineLibrary

Assembly (DLL)

WS PortalASP.NET

Assembly (DLL)

Client BApplication

Assembly (EXE)

Client CApplication

Assembly (EXE)

LogbookLibrary

Assembly (DLL)

Service B Manager Library

Assembly (DLL)

Service B Res Access

Library Assembly (DLL)

Service B EngineLibrary

Assembly (DLL)

LogbookLibrary

Assembly (DLL)

Service C Manager Library

Assembly (DLL)

Service C Res Access

Library Assembly (DLL)

Service B EngineLibrary

Assembly (DLL)

LogbookLibrary

Assembly (DLL)

Service D Manager Library

Assembly (DLL)

Service A Res Access

Library Assembly (DLL)

Service D EngineLibrary

Assembly (DLL)

LogbookLibrary

Assembly (DLL)

HostApplication

Assembly (EXE)

HostApplication

Assembly (EXE)

HostApplication

Assembly (EXE)

LogbookLibrary

Assembly (DLL)

Logbook ViewerApplication

Assembly (EXE)

Identity ManagementProcess boundary enables identity boundary

Not mandates itAssign identities based on credentials required to operateTypically

Clients and manager do not share identityThe further from the client the less relevant its identity is

Managers from different processes may share identities Strive to minimize overall number of identities Use designated identities

Group all services that share identity and enclose in a box

Security

AdminClient

Logging

Pub/Sub

.

.

.

Reports

SupportResource1

Service AEngine

Service ARes Access

Service AManager

Service BEngine

Service BManager

Service CEngine

Service CManager

Service DEngine

Service DManager

Resource2

Service BRes Access

Service CRes Access

Service DRes Access

Client A Client DClient B Client C Host

Trusted Sub System PatternPrefer trusted sub-system patternWorks well in a multi-tier design Every layer

Authenticates its immediate caller Implicitly trusts its caller to authenticate its callersAuthorizes its callers via role-based security

Identities are not fully propagated downwardsCan construct audit trail by

Composing local audits Propagate full stack trace

Call AuthenticationTypically

Every logical layer crossing is authenticatedEvery cross-process call is authenticated

Do authenticate in-proc servicesFor message protection with Windows creds

Mark authentication boundary with a solid bar

Security

AdminClient

Logging

Pub/Sub

.

.

.

Reports

SupportResource1

Service AEngine

Service ARes Access

Service AManager

Service BEngine

Service BManager

Service CEngine

Service CManager

Service DEngine

Service DManager

Resource2

Service BRes Access

Service CRes Access

Service DRes Access

Client A Client DClient B Client C Host

Call AuthorizationAuthorization meaningless without authentication Typically

Every logical layer crossing is authorized Every cross process call is authorized

No point in authorizing calls to in-proc servicesShared identity

Authorization does not necessarily coincide with authenticationMark authorization boundary with patterned bar

Security

AdminClient

Logging

Pub/Sub

.

.

.

Reports

SupportResource1

Service AEngine

Service ARes Access

Service AManager

Service BEngine

Service BManager

Service CEngine

Service CManager

Service DEngine

Service DManager

Resource2

Service BRes Access

Service CRes Access

Service DRes Access

Client A Client DClient B Client C Host

TransactionsGuidelines

Start transactions as up-stream as possibleEngulf as much as possibleKeep transactions short

Under 1 secondGroup all services and resources in same transaction with a boxTypically

Managers are Client/Service modeEngines, resources access are Client mode Utilities are Service mode

Security

AdminClient

Logging

Pub/Sub

.

.

.

Reports

SupportResource1

Service AEngine

Service ARes Access

Service AManager

Service BEngine

Service BManager

Service CEngine

Service CManager

Service DEngine

Service DManager

Resource2

Service BRes Access

Service CRes Access

Service DRes Access

Client A Client DClient B Client C Host

SynchronizationIdentify logical thread of executionAny reentrant cyclic path implies

DeadlockPoor design and reentrancy Need for queuing Need for async event publishing

Security

AdminClient

Logging

Pub/Sub

.

.

.

Reports

SupportResource1

Service AEngine

Service ARes Access

Service AManager

Service BEngine

Service BManager

Service CEngine

Service CManager

Service DEngine

Service DManager

Resource2

Service BRes Access

Service CRes Access

Service DRes Access

Client A Client DClient B Client C Host

ResourcesProgramming WCF Services 3rd Edition

Juval Löwy, O'Reilly 2010www.idesign.net

Code libraryCoding standardSample architecture reportIDesign Method™

Master ClassesArchitect’s Master Class November 15-19, California

http://www.idesign.net/idesign/download/IDesignCD.zip

More at TechEdA Modular Approach to Development Process

Wednesday 5:00 PMAppFabric Service Bus Design Patterns

Thursday 9:45 AM

Resources

www.microsoft.com/teched

Sessions On-Demand & Community Microsoft Certification & Training Resources

Resources for IT Professionals Resources for Developers

www.microsoft.com/learning

http://microsoft.com/technet http://microsoft.com/msdn

Learning

Complete an evaluation on CommNet and enter to win!

Sign up for Tech·Ed 2011 and save $500 starting June 8 – June 31st

http://northamerica.msteched.com/registration

You can also register at the

North America 2011 kiosk located at registrationJoin us in Atlanta next year

JUNE 7-10, 2010 | NEW ORLEANS, LAJUNE 7-10, 2010 | NEW ORLEANS, LA