Juval Lowy IDesign www.idesign.net SESSION CODE: ARC206 The Zen of Architecture ©2010 IDesign Inc. All rights reserved
Juval Lowy IDesign SESSION CODE: ARC206 The Zen of Architecture ©2010 IDesign Inc. All rights reserved.
Dec 13, 2015
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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
Related Documents
