The Microkernel pattern partitions an operating system into isolated, minimal components that communicate through a small, fixed message-passing interface, allowing components to be developed and upgraded independently while maintaining overall system stability and security.

1. More
architectural styles
Paolo Ciancarini

2. Agenda
• Examples of distributed systems
• POSA: Pattern oriented sw architecture
• Architectural pattern for distributed systems: Broker
• Architectural pattern for distributed systems: Microkernel
2

3. 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)

4. Pattern oriented software architecture

5. 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)

6. POSA 1

7. The POSA2 Pattern Language
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

8. POSA2 Pattern Abstracts
Service Access & Configuration Patterns Event Handling Patterns
The Wrapper Facade design pattern The Reactor architectural pattern allows event-
encapsulates the functions and data provided by driven applications to demultiplex and dispatch
existing non-object-oriented APIs within more service requests that are delivered to an
concise, robust, portable, maintainable, and application from one or more clients.
cohesive object-oriented class interfaces.
The Proactor architectural pattern allows
The Component Configurator design pattern event-driven applications to efficiently
allows an application to link and unlink its demultiplex and dispatch service requests
component implementations at run-time without triggered by the completion of asynchronous
having to modify, recompile, or statically relink the operations, to achieve the performance
application. Component Configurator further benefits of concurrency without incurring
supports the reconfiguration of components into certain of its liabilities.
different application processes without having to
The Asynchronous Completion Token design
shut down and re-start running processes.
pattern allows an application to demultiplex
The Interceptor architectural pattern allows and process efficiently the responses of
services to be added transparently to a asynchronous operations it invokes on
framework and triggered automatically when services.
certain events occur.
The Acceptor-Connector design pattern
The Extension Interface design pattern allows decouples the connection and initialization of
multiple interfaces to be exported by a cooperating peer services in a networked
component, to prevent bloating of interfaces and system from the processing performed by the
breaking of client code when developers extend peer services after they are connected and
or modify the functionality of the component. initialized.

9. POSA2 Pattern Abstracts
Synchronization Patterns Concurrency Patterns
The Scoped Locking C++ idiom The Active Object design pattern decouples method
ensures that a lock is acquired when execution from method invocation to enhance concurrency
control enters a scope and released and simplify synchronized access to objects that reside in
automatically when control leaves the their own threads of control.
scope, regardless of the return path
The Monitor Object design pattern synchronizes concurrent
from the scope.
method execution to ensure that only one method at a time
The Strategized Locking design pattern runs within an object. It also allows an object’s methods to
parameterizes synchronization cooperatively schedule their execution sequences.
mechanisms that protect a component’s
The Half-Sync/Half-Async architectural pattern decouples
critical sections from concurrent access.
asynchronous and synchronous service processing in
The Thread-Safe Interface design concurrent systems, to simplify programming without unduly
pattern minimizes locking overhead and reducing performance. The pattern introduces two
ensures that intra-component method intercommunicating layers, one for asynchronous and one
calls do not incur ‘self-deadlock’ by for synchronous service processing.
trying to reacquire a lock that is held by
The Leader/Followers architectural pattern provides an
the component already.
efficient concurrency model where multiple threads take
The Double-Checked Locking turns sharing a set of event sources in order to detect,
Optimization design pattern reduces demultiplex, dispatch, and process service requests that
contention and synchronization occur on the event sources.
overhead whenever critical sections of
The Thread-Specific Storage design pattern allows multiple
code must acquire locks in a thread-
safe manner just once during program threads to use one ‘logically global’ access point to retrieve
an object that is local to a thread, without incurring locking
execution.
overhead on each object access.

10. POSA 3 patterns (resource management)

11. POSA 4
patterns

13. Enterprise application patterns (Fowler)
• See pattern Layers in [POSA]
• Here: applied to enterprise
applications
• Presentation logic
Presentation logic
– Interaction with user
– Command-line or rich client or Web
interface
• Domain logic
– Validation of input and calculation of Domain logic
results
• Data source logic
– Communication with database and
other applications Data source logic

14. EA Patterns
Data Source Domain Presentation Page Controller Template View
Front Controller Transform View
Domain Model
Transaction Script
Active Record Table Module
Data Mapper
Row Data Gateway Table Data Gateway
martinfowler.com/eaaCatalog/

15. J2EE
patterns
www.corej2eepatterns.com!

16. Motivation
Trends
• Hardware keeps getting smaller, faster, & cheaper
• Software keeps getting larger, slower, & more expensive
AbstractService
Historical Challenges
service
• Building distributed systems is hard Client
• Building them on-time & under budget is
even harder Proxy Service
1 1
service service
New Challenges
• 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
16

17. Mission-Critical Applications
Large-scale Switching Systems
IOM IOM
Total Ship Computing Environments
IOM BSE BSE BSE IOM Total Ship C&C Center
IOM IOM
IOM IOM
IOM BSE BSE BSE IOM
IOM IOM
IOM IOM
IOM BSE BSE BSE IOM
IOM IOM
Avionics
Industrial Process Control Theater Missile Defense
17

18. Examples of Distributed
Systems
• Automatic Teller Machine (ATM)
• Web-based travel site
• Stock transaction processing system
• Search service
• Multiplayer games

19. Automatic Teller Machine
(“bancomat”)
• Client-server, server knows all clients
• Simple reply-response
• Transactions
• Tightly controlled distributed system
• High security

20. 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

21. Stock Transaction Processing
• Peer-to-peer communication
• Lots of clients (QoS: isochrony)
• Different markets
• Publish/subscribe model for many
interactions

22. Search Engine Service
• Example: Google toolkit
• Language-neutral service
• Freely available
• Easy to write program exploiting its
services
• Low support overhead

23. Discuss
What do these applications all need?

24. What They All Need
• Communication infrastructure
• Remote references to objects and
methods
• Remote method invocation or remote
procedure call

25. 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

26. 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

27. 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)

28. 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

29. Some patterns for concurrency and
distribution (POSA2)
• Broker
• Microkernel
• Pipes and filters
• Reactor
• Pool of threads
• ….

30. 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

31. 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
32

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
33

34. Broker pattern: context
Your environment is a distributed and
possibly heterogeneous system with
independent cooperating components.
34

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
35

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
36

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
37

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
38

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
39

40. Broker pattern: structure
• Participating components
– Clients
– Servers
– Brokers
– Bridges
– Client-side proxies
– Server-side proxies
40

41. Class Collaborators Class Collaborators
Client Client-side proxy Server Server-side proxy
Responsibility Broker Responsibility Broker
- implements user - implements
functionality services
- sends requests - registers itself
with the local broker
to servers through
- Send responses
a client-side proxy and exceptions
back to clients via
a server-side proxy

42. 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
43

44. Server Registration

45. Client requests a service

46. 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
47

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
48

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
49

50. 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

51. 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
54

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
55

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
56

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
57

58. CRC Cards
Class Collaborators
Internal server Microkernel
Class Collaborators
Responsibility
Microkernel Internal server
 Implements
Responsibility
additional services
 Provides core
 Encapsulates
mechanisms
some system
 Offers communi-
dependencies
cation facilities
 Encapsulates sys-
Class Collaborators
tem dependencies
External server Microkernel
 Manages and
controls resources Responsibility
• Provides
programming
interfaces for
its clients
58

59. CRC cards
Class Collaborators Class Collaborators
 Client Adapter  Adapter External server
Microkernel
Responsibility
Responsibility Hides system depen-
 Represents an dencies such as
application communication
facilities from the
client.
Invokes methods of
external servers on
behalf of clients
59

60. Static Relationships
External Server Microkernel Internal Server
receiveRequest executeMechanism receiveRequest
dispatchRequest initCommunication executeService
executeService findReceiver
createHandle
sendMessage
callInternalServer
initializes
communication
Adapter Client
createRequest doTask
calls service
callService
sends request
60

61. Microkernel

62. Scenario I
62

63. Scenario II
63

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
64

65. Consequences
• Benefits
– portability
– flexibility and extensibility
– separation of policy and mechanism
– scalability
– reliability
– transparency
• Liabilities
– performance
– complexity of design and implementation
65

66. Self test questions
• 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?
66

67. 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/

68. Useful sites
• www.bredemeyer.com/links.htm!
• www.opengroup.org/architecture/!
• www.iasahome.org!
• java.sun.com/blueprints/corej2eepatterns/!

69. Questions?