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?