Introduction to architectural patterns
-
Upload
georgy-podsvetov -
Category
Software
-
view
373 -
download
0
Transcript of Introduction to architectural patterns
Layered architecture
closed • Presenta)on layer
closed • Business layer
closed • Persistence layer
Closed • Database layer
• Layers communicate from top to down only • To get layer below, you have to go through all in the middle
3
What if we have some kind of shared services?
closed • Presenta)on layer
closed • Business layer
closed • Services layer
closed • Persistence layer
Closed • Database layer
Do we s)ll need pass all request throw this layer?
4
Open layered architecture
closed • Presenta)on layer
closed • Business layer
open • Services layer
closed • Persistence layer
Closed • Database layer
Some layers might be open.
5
Layered architecture
• Good general purpose architecture • Easy to implement, test, and govern • Good star)ng point for most systems • Not always op)mized for specific business drivers
closed • Presenta)on layer
closed • Business layer
closed • Services layer
closed • Persistence layer
Closed • Database layer
closed • Presenta)on layer
closed • Business layer
open • Services layer
closed • Persistence layer
Closed • Database layer
6
Event processor topology
Event queue
Event processor
Event topic
Event topic
processor processor processor processor processor
Event orchestra)on
8
Broker topology
Event topic
Event topic
processor
processor
processor processor
processor
Event topic
Event
processor
processor
processor
media)on
9
Event-‐driven architecture
• Highly decoupled and distributed • Highly scalable • High degree of complexity • Good for event-‐based business models and business processes
• Not good for processes which require a high degree of data sharing, orchestra)on, and reuse
11
Service-‐oriented architecture Business services
Enterprise services
Applica)on services Infrastructure services
Message bus
BS BS BS BS BS
ES ES ES ES ES
AS IS
Process choreographer
Service orchestrator
12
Business services
Abstract service used to represent a business process or func)on independent of the underlying technology or pa1ern • Сan be derived from use cases, user
stories, user scenarios • Contains a service name, input
specifica)on, and output specifica)on • Course-‐grained • Shared across the enterprise
Business services
Enterprise services
Applica)on services Infrastructure services
Message bus
BS BS BS BS BS
ES ES ES ES ES
AS IS
Process choreographer Service orchestrator
13
Enterprise services
Concrete services that implement Business Services
Business services
Enterprise services
Applica)on services Infrastructure services
Message bus
BS BS BS BS BS
ES ES ES ES ES
AS IS
Process choreographer Service orchestrator
• The rela)onship between an Enterprise Service and a Business Service is either a one-‐to-‐one or many-‐to-‐one rela)onship
• Course-‐grained • Represent ac)ons against major data
en))es • Usually require some sort of service
orchestra)on • Shared across the enterprise 14
Applica)on services
Implementa)on of applica)on-‐specific func)ons, such as database querying, valida)on, etc.
Business services
Enterprise services
Applica)on services Infrastructure services
Message bus
BS BS BS BS BS
ES ES ES ES ES
AS IS
Process choreographer Service orchestrator
• Concrete defini)on • Defined by applica)on developers • Fine-‐grained • Tightly bound to a specific applica)on
context • Generally not shared across the
enterprise
15
Infrastructure services
Implementa)on of the non-‐business related func)ons, like logging, error handling, single sign on, etc.
Business services
Enterprise services
Applica)on services Infrastructure services
Message bus
BS BS BS BS BS
ES ES ES ES ES
AS IS
Process choreographer Service orchestrator
• Concrete defini)on • Defined by applica)on or system
developers • Fine-‐grained • Supports the system or enterprise
infrastructure • Shared across the enterprise
16
Message Bus
Coordinates services and processes, it’s a glue for SOA components
Business services
Enterprise services
Applica)on services Infrastructure services
Message bus
BS BS BS BS BS
ES ES ES ES ES
AS IS
Process choreographer Service orchestrator
• Process choreography • Service orchestra)on • Service registry • Protocol transforma)on • Message enhancement and
transforma)on
17
Service-‐oriented architecture
• Good pa1ern for understanding and implemen)ng business processes and services
• Very high level of complexity • Difficult to implement due to complex tools, hype, misconcep)ons, and heavy business user involvement
• Good pa1ern for large, complex, heterogeneous businesses that have a large number of common services
18
Pipes and filters
• Uni-‐direc)onal only • Usually point-‐to-‐point for high performance, but could be message-‐based for scalability
• Payload can be any type
pipe
filter • Self-‐contained and independent from other filters
• Usually designed to perform a single specific task
20
Filter types
Producer
Tester
Consumer
pipe
pipe
Transformer pipe pipe
pipe pipe
Star)ng point, outbound only
Input, processing, output
Input, discard or pass-‐thru
Endpoint, inbound only
21
Pipeline architecture
• Useful for smaller determinis)c systems with a dis)nct processing flow
• Filters can easily be added and removed • Provides for a high level of decoupling • Supports evolu)onary design • Able to easily adapt to changing requirements • Can be easily incorporated into another pa1ern Producer Transformer Transformer
Tester Consumer
pipe pipe
pipe
pipe
22
Microkernel architecture
Core
Plug-‐in module
Plug-‐in module
Plug-‐in module
Plug-‐in module
Plug-‐in module
23
Microkernel architecture
• Minimal func)onality to run system • General business rules and logic • Doesn’t contain custom processing
Core
Plug-‐in module
• Standalone independent module • Specific addi)onal rules or logic
Core
Plug-‐in module
Plug-‐in module
Plug-‐in module
Plug-‐in module
Plug-‐in module
24
Microkernel architecture
• Useful for systems that have custom processing or processing is suscep)ble to change
• Plug-‐in modules can be easily added and removed
• Supports evolu)onary design • Able to easily adapt to changing requirements • Can easily be incorporated into another pa1ern
Core
Plug-‐in module
Plug-‐in module
Plug-‐in module
Plug-‐in module
Plug-‐in module
25
Space-‐based architecture
Virtualized middleware
Messaging grid Data grid Processing grid Deployment manager
Processing unit
-‐ -‐ -‐ -‐ -‐ -‐ -‐
Processing unit
-‐ -‐ -‐ -‐ -‐ -‐ -‐
Processing unit
-‐ -‐ -‐ -‐ -‐ -‐ -‐
26
Processing unit
Module Module Module
DB In-‐memory data
Data replica)on engine
In fact it is standalone version of yours applica)on
27
Virtualized middleware
Manages input request and session
Messaging grid
Data grid
Processing grid
Deployment manager
Manages data replica)on between processing units
Manages parallel request processing
Manages dynamic processing unit deployment
28
Space-‐based architecture
• Good for applica)ons that have variable load or inconsistent peak )mes
• Not good fit for tradi)onal large-‐scale rela)onal database systems
• Rela)vely complex and expensive pa1ern to implement
Virtualized middleware
Messaging grid Data grid Processing
grid Deployment manager
Processing unit
-‐ -‐ -‐ -‐ -‐
Processing unit
-‐ -‐ -‐ -‐
Processing unit
-‐ -‐ -‐ -‐ -‐
29
h1p://goo.gl/BiV940
h1p://goo.gl/vmv0Ww
h1p://goo.gl/NI6uE2
h1p://goo.gl/XEw0JB
Ques)ons?
Georgiy Podsvetov [email protected]
Recommended reading:
h1p://ua.linkedin.com/pub/georgiy-‐podsvetov/45/989/868
h1ps://www.facebook.com/GeorgiyPodsvetov 30