Paolo Ciancarini More architectural styles
Paolo Ciancarini
More architectural styles
2
Agenda • Examples of distributed systems • POSA: Pattern oriented sw architecture • Architectural pattern for distributed systems: Broker • Architectural pattern for distributed systems: Microkernel
Complex architectural styles
• The basic architectural styles (layers, tiers, pipes, repository, MVC, client-server, peer-to-peer) are not sufficient to describe all current (and future) software systems
• They can be combined in several ways • They exploit different patterns • Moreover, some systems expose special
styles (eg. mobile code, agent-based, etc)
Pattern oriented software architecture
References • Buschmann et al. Pattern-Oriented Software
Architecture: a system of patterns, Wiley 1996 (POSA1)
• Schmidt et al., Patterns for Concurrent and Networked Objects, Wiley 2000 (POSA2)
• Kircher and Jain, Patterns for Resource Management, Wiley 2004 (POSA3)
• Buschmann et al. Pattern Language for distributed computing, Wiley 2007 (POSA4)
• Buschmann et al. Pattern-Oriented Software Architecture, Wiley 2007 (POSA5)
POSA 1
Pattern Benefits • Preserve crucial design information used by applications & middleware frameworks & components
• Facilitate reuse of proven software designs & architectures
• Guide design choices for application developers
The POSA2 Pattern Language
POSA2 Pattern Abstracts Service Access & Configuration Patterns
The Wrapper Facade design pattern encapsulates the functions and data provided by existing non-object-oriented APIs within more concise, robust, portable, maintainable, and cohesive object-oriented class interfaces.
The Component Configurator design pattern allows an application to link and unlink its component implementations at run-time without having to modify, recompile, or statically relink the application. Component Configurator further supports the reconfiguration of components into different application processes without having to shut down and re-start running processes.
The Interceptor architectural pattern allows services to be added transparently to a framework and triggered automatically when certain events occur.
The Extension Interface design pattern allows multiple interfaces to be exported by a component, to prevent bloating of interfaces and breaking of client code when developers extend or modify the functionality of the component.
Event Handling Patterns
The Reactor architectural pattern allows event-driven applications to demultiplex and dispatch service requests that are delivered to an application from one or more clients.
The Proactor architectural pattern allows event-driven applications to efficiently demultiplex and dispatch service requests triggered by the completion of asynchronous operations, to achieve the performance benefits of concurrency without incurring certain of its liabilities.
The Asynchronous Completion Token design pattern allows an application to demultiplex and process efficiently the responses of asynchronous operations it invokes on services.
The Acceptor-Connector design pattern decouples the connection and initialization of cooperating peer services in a networked system from the processing performed by the peer services after they are connected and initialized.
POSA2 Pattern Abstracts Synchronization Patterns The Scoped Locking C++ idiom ensures that a lock is acquired when control enters a scope and released automatically when control leaves the scope, regardless of the return path from the scope. The Strategized Locking design pattern parameterizes synchronization mechanisms that protect a component’s critical sections from concurrent access. The Thread-Safe Interface design pattern minimizes locking overhead and ensures that intra-component method calls do not incur ‘self-deadlock’ by trying to reacquire a lock that is held by the component already. The Double-Checked Locking Optimization design pattern reduces contention and synchronization overhead whenever critical sections of code must acquire locks in a thread-safe manner just once during program execution.
Concurrency Patterns The Active Object design pattern decouples method execution from method invocation to enhance concurrency and simplify synchronized access to objects that reside in their own threads of control.
The Monitor Object design pattern synchronizes concurrent method execution to ensure that only one method at a time runs within an object. It also allows an object’s methods to cooperatively schedule their execution sequences. The Half-Sync/Half-Async architectural pattern decouples asynchronous and synchronous service processing in concurrent systems, to simplify programming without unduly reducing performance. The pattern introduces two intercommunicating layers, one for asynchronous and one for synchronous service processing.
The Leader/Followers architectural pattern provides an efficient concurrency model where multiple threads take turns sharing a set of event sources in order to detect, demultiplex, dispatch, and process service requests that occur on the event sources.
The Thread-Specific Storage design pattern allows multiple threads to use one ‘logically global’ access point to retrieve an object that is local to a thread, without incurring locking overhead on each object access.
POSA 3 patterns (resource management)
POSA 4 patterns
Enterprise application patterns (Fowler)
• See pattern Layers in [POSA] • Here: applied to enterprise
applications • Presentation logic
– Interaction with user – Command-line or rich client or Web
interface • Domain logic
– Validation of input and calculation of results
• Data source logic – Communication with database and
other applications
Presentation logic
Data source logic
Domain logic
EA Patterns
Doma
in Da
ta So
urce
Transaction Script Domain Model
Data Mapper
Row Data Gateway
Front Controller
Template View
Transform View
Page Controller Pr
esen
tation
Active Record Table Module
Table Data Gateway
martinfowler.com/eaaCatalog/
J2EE patterns
www.corej2eepatterns.com!
16
Historical Challenges
Motivation Trends
• Many mission-critical distributed applications require real-time QoS support • e.g., combat systems, online trading, telecom
• Building QoS-enabled applications manually is tedious, error-prone, & expensive
• Conventional middleware does not support real-time QoS requirements effectively
• Building distributed systems is hard • Building them on-time & under budget is even harder
• Hardware keeps getting smaller, faster, & cheaper
1 1 Proxy
service
Service
service
AbstractService
service
Client
• Software keeps getting larger, slower, & more expensive
New Challenges
17
Mission-Critical Applications Large-scale Switching Systems
Avionics
IOM
IOM
IOM
IOM
IOM
IOM
IOM
IOM
IOM
IOM
IOM
IOM
IOM
IOM
IOM
IOM
IOM
IOM
BSE
BSE
BSE
BSE
BSE
BSE
BSE BSE
BSE
Industrial Process Control Theater Missile Defense
Total Ship C&C Center
Total Ship Computing Environments
Examples of Distributed Systems
• Automatic Teller Machine (ATM) • Web-based travel site • Stock transaction processing system • Search service • Multiplayer games
Automatic Teller Machine (“bancomat”)
• Client-server, server knows all clients • Simple reply-response • Transactions • Tightly controlled distributed system • High security
Web-Based Travel Site
• Multi-tiered – Client – Travel site – Vendors’ reservation systems – Referred to as n-tiered
• Organization responsible for the site has little or no control over other tiers
• Session-oriented, indefinite seq of msgs
Stock Transaction Processing
• Peer-to-peer communication • Lots of clients (QoS: isochrony) • Different markets • Publish/subscribe model for many
interactions
Search Engine Service
• Example: Google toolkit • Language-neutral service • Freely available • Easy to write program exploiting its
services • Low support overhead
Discuss What do these applications all need?
What They All Need
• Communication infrastructure • Remote references to objects and
methods • Remote method invocation or remote
procedure call
Special Needs • Transactions
– ATM – Stock transaction processing
• Asynchronous Messaging – Stock transaction processing
• Session support (shared state) – Travel site
• Language neutrality – standard interfaces – Travel site – Stock transaction processing – Google search service
Synchronous communication
• Remote procedure call (RPC) • Remote method invocation (RMI) • Client waits until server responds, or request
times out • Most distributed processing follows this model • Is much like normal, non-distributed
programming, but… – Pass by reference is not practical – Not all data types may be available – Platform neutrality may be hard to achieve
Asynchronous communication
• Messaging – Client sends a message and moves on – If a response is needed, the client has a mechanism
that listens for it • Point-to-point • Used in publish/subscribe applications, e.g. • Uses message-oriented middleware (MOM)
Message-Oriented Middleware
• IBM MQ Series • Oracle AQS • JMS – Java Messaging Service
– Part of the J2EE standard – A set of standard interfaces, not a defined
implementation – Many vendors provide JMS wrappers or
adapters for their MOM
Some patterns for concurrency and distribution (POSA2)
• Broker • Microkernel • Pipes and filters • Reactor • Pool of threads • ….
Broker
• A broker is a party which mediates between a buyer and a seller
• In computing, a broker can be: – A message broker – A object request broker
Broker
32
Basic Pattern Format • Name and summary description • Example • Context • Problem, including forces • Solution • Implementation • Example Resolved • Variants • Known Uses • Consequences: benefits and liabilities • Related Patterns and Credits
33
Description of the Broker pattern
• Goal: structure distributed sw systems – with decoupled components – that interact by remote service invocations
• Responsible for – coordinating communication – transmitting results – transmitting exceptions
34
Broker pattern: context
“Your environment is a distributed and possibly heterogeneous system with independent cooperating components.”
35
Broker pattern: problem • Build a complex sw system as a set of
decoupled, interoperating components (rather than a monolith) – Greater flexibility, maintainability, changeability – Partitioning into independent components makes
system distributable and scalable • Require a means of inter-process communication
– If components themselves handle communication, result has several dependencies and limitations
• System depends on which comm mechanism used • Clients need to know location of servers
36
Broker pattern: problem • Need services for adding, removing,
exchanging, activating, and locating components – Must not depend on system-specific details
to guarantee portability and interoperability • An object that uses an object should only
see the interface offered by the object – know nothing about implementation
37
Broker pattern: forces Broker pattern balances the following forces • Components access others’ services via
remote, location-transparent service invocations
• Need to exchange, add, or remove components at run-time
• Architecture should hide system-specific and implementation-specific details from users of components and services
38
Broker pattern: solution • Introduce a broker component to achieve better
decoupling of clients and servers – Servers: register themselves with the broker and
make their services available to clients through method interfaces.
– Clients: access the functionality of servers by sending requests via the broker
• A broker’s tasks: – Locating the appropriate server and forwarding a
request to that server – Transmitting results and exceptions back to the client
39
Broker pattern: solution • Reduces the complexity involved in developing
distributed applications. – Introduces object model where distributed services are
encapsulated within objects
• Broker systems offer a path to the integration of two core technologies: – Distribution – Object technology
• Extend object models from single applications to distributed applications made of decoupled components that can – run on heterogeneous machines and – written in different programming languages
40
Broker pattern: structure
• Participating components – Clients – Servers – Brokers – Bridges – Client-side proxies – Server-side proxies
Class Collaborators Client Client-side proxy Responsibility Broker - implements user functionality - sends requests to servers through a client-side proxy
Class Collaborators Server Server-side proxy Responsibility Broker - implements services - registers itself with the local broker - Send responses and exceptions back to clients via a server-side proxy
Class Collaborators Broker Client Responsibility Server Client-side proxy - registers servers Server side proxy - offers API Bridge - sends requests - transfer msgs - error recovery - locates servers -interoperates with other brokers through bridges
43
Broker class diagram
Server Registration
Client requests a service
Broker forwards a request
47
Broker pattern: implementation 1. Define an object model or use an existing one 2. Decide which kind of component-interoperability the
system should offer 3. Specify the APIs the broker component provides for
collaborating with clients and servers 4. Use proxy objects to hide implementation details from
clients and servers 5. Design the broker component in parallel with steps 3
and 4 • broken down into nine steps
6. Develop IDL compilers
48
Broker pattern: known uses
• CORBA • Microsoft’s OLE • WWW – Hypertext browsers such as
Mosaic and Netscape act as brokers and WWW servers play the role of service providers
49
Broker Pattern: consequences
• Benefits – Location transparency – Changeability and extensibility of components – Portability of a Broker system – Interoperability between different Broker systems – Reusability
• Liabilities – Restricted efficiency – Lower fault tolerance (server fails, broker fails, ...) – Testing and debugging
Object request broker
• An object request broker (ORB) is a piece of software that allows to make program calls from one computer to another via a network
• ORBs promote interoperability of distributed object systems because they enable users to build systems by piecing together objects from different vendors, so that they communicate with each other via the ORB
Object Request Broker (CORBA)
54
Microkernel pattern • Found in POSA 1, pp. 171-192
(also found in Real-Time Design Patterns) • The Microkernel architectural pattern applies
to software systems that must be able to adapt to changing system requirements
• It separates a minimal functional core from extended functionality and customer-specific parts
• The microkernel also serves as a socket for plugging in these extensions and coordinating their collaboration
55
Context & Problem • Context: The development of several
applications that use similar programming interfaces that build on the same core functionality
• Problem: develop software for a domain that needs to cope with a broad spectrum of similar standards and technologies. Systems like operating systems and GUI’s often have a long life-span. New technologies emerge; old ones change
56
Forces • Application platform must cope with continuous hw and
sw evolution • Application platform should be portable, extensible,
and adaptable to allow easy integration of emerging technologies
• Applications in the domain need to support different but similar application platforms.
• The applications may be categorized into groups – use the same functional core in different ways – require the underlying application platform to
emulate existing standards. • Functional core separate component with minimal
memory size and services that consume as little processing as possible
57
Solution • Encapsulate fundamental services in a microkernel
component • Internal servers contain core functionality that cannot
be implemented in the microkernel without causing an unnecessary increase in size or complexity
• External servers implement their own view of the underlying microkernel using mechanisms available through the interfaces of the microkernel – Every external server is a separate process that
represents an application platform • A microkernel system is an application platform that
integrates other application platforms • Clients communicate with ext. servers using comm
facilities provided by microkernel
58
CRC Cards
Class Collaborators Microkernel Internal server Responsibility Provides core mechanisms Offers communi- cation facilities Encapsulates sys- tem dependencies Manages and controls resources
Class Collaborators Internal server Microkernel Responsibility Implements additional services Encapsulates some system dependencies Class Collaborators External server Microkernel Responsibility • Provides
programming interfaces for its clients
59
CRC cards Class Collaborators Client Adapter
Responsibility Represents an application
Class Collaborators Adapter External server Microkernel Responsibility Hides system depen- dencies such as communication facilities from the client. Invokes methods of external servers on behalf of clients
60
Static Relationships External Server receiveRequest dispatchRequest executeService
Microkernel executeMechanism initCommunication findReceiver createHandle sendMessage callInternalServer
Adapter createRequest callService
Client doTask
Internal Server receiveRequest executeService
initializes communication
sends request
calls service
Microkernel
62
Scenario I
63
Scenario II
64
Examples • Windows NT, Linux 2.*, MACH, etc. • Most real time operating systems (RTOS) for
embedded systems • Core set of services include create and delete a task,
allocate and de-allocate memory, provide task event & message queues, and schedule/execute a task set
• A developer can link in additional components to provide more services: like bus communications, file services, networking services, and middleware services
• A microkernel RTOS becomes usable in a much wider set of application problems from tiny, highly memory-constrained systems to systems consisting of sets of high-powered networked CPUs
65
Consequences • Benefits
– portability – flexibility and extensibility – separation of policy and mechanism – scalability – reliability – transparency
• Liabilities – performance – complexity of design and implementation
Self test questions
66
• How many architectural styles (or patterns) do exist?
• What is the relationship between style and architecture?
• What are the consequences of the broker pattern?
• What are the consequences of the microkrnel pattern?
References • M. Fowler Patterns of Enterprise Application
Architecture, Addison Wesley, 2003 • L.Bass and P. Clemens and R. Kazman,
Software Architecture in Practice, 2nd Ed, Addison Wesley, 2003
• Gardner and Yusuf, Capturing your architectural decisions explicitly, 2006 www.ibm.com/developerworks/library/ar-mdd2/
Useful sites • www.bredemeyer.com/links.htm!• www.opengroup.org/architecture/!• www.iasahome.org!• java.sun.com/blueprints/corej2eepatterns/!
Questions?