Patterns Architectural Styles Archetypes - VUdonatas/PSArchitekturaProjektavimas...Patterns The purpose of a pattern is to share a proven, widely applicable solution to a particular

Patterns

Architectural Styles

Archetypes

Patterns The purpose of a pattern is to share a proven, widely

applicable solution to a particular problem in a standard form that allows it to be easily reused.

Many types of patterns have been identified:

organizational patterns,

process patterns,

analysis patterns,

design patterns, and so on.

Patterns and Architectural Styles 2

Pattern Description Pattern is usually described by the following five important pieces of

information: Name: A pattern needs a memorable and meaningful name to allow us

to clearly identify and discuss the pattern and, more important, to use its name as part of our design language when discussing possible solutions to design problems.

Context: This sets the stage for the pattern, explains its motivation and rationale, and describes the situations in which the pattern may apply.

Problem: A common way to describe the problem the pattern is intended to solve is to describe the design forces it aims to resolve, each force being a goal, requirement, or constraint that informs or influences the solution.

Solution: some form of design model, explaining the elements of the design and how they work together to solve the problem.

Consequences: a clear statement of the results and tradeoffs of pattern’s application, to allow to decide whether it is a suitable solution to the problem. This should include both positive consequences (benefits) and negative consequences (costs).


Pattern Types We are interested in three types of design patterns:

the architectural styles, which captures system-level structures;

the software design patterns, which captures a more detailed software design solution; and

the language idioms, which provides a solution for a recurring programming-language-specific design problem.


Language Idioms A language idiom is a pattern specific to a

programming language.

Example 1: C programming language string copy routine:

void strCopy(char *d, const char *s) {

while (*d++ = *s++);

}


Language Idioms: Example 2 Singleton design pattern in Java:

public class A {

private static final A INSTANCE = new A();

private A() {

...

}

public static A getInstance() {

return INSTANCE;

}

}


Language Idioms: other examples equals() and hashCode() methods in Java

Checked/unchecked exception type usage, exception class hierarchies, where exceptions are thrown and where caught, etc.

Developers should adopt code standard and stick to it


Software Design PatternsBook “Design Patterns: Elements of Reusable Object-Oriented Software”, 1994


What varies Design Pattern

Algorithms Strategy, Visitor

Actions Command

Implementations Bridge

Response to change Observer

Interactions between objects Mediator

Object being created Factory Method, Abstract Factory, Prototype

Structure being created Builder

Traversal Algorithm Iterator

Object interfaces Adapter

Object behavior Decorator, State

“Gang of Four” design patterns became classics in object-oriented programming

Architectural Style An architectural style expresses a fundamental

structural organization schema for software systems. It provides a set of predefined element types, specifies

their responsibilities, and includes rules and guidelines for organizing the relationships between them.

Shortly, architectural style provides: element types,

relationship types,

restrictions for both.

Architectural styles are means to structurally decompose a system to smaller parts


Commonly used styles for web-based business software systemsBook “Pattern-Oriented Software Architecture Volume 1 - A System Of Patterns”, 2001

Multi-tier / n-tier / Tiered Computing

Layers

Model-View-Controller (MVC)

Publish/Subscribe

Broker

Other: CRUD

CQRS

Event Sourcing


Multi-tier Architectural Style A development of the Client/Server style, the Multi-tier

style is widely used in business software systems. Also known as “n-tier” and “Tiered Computing”

A tiered system is considered to contain a number of tiersof computation, which combine to offer a service to an ultimate consumer (e.g., a human user).

Each tier acts as a server for its caller and as a client to the next tier in the architecture.

A key architectural principle is that: a tier can communicate in this way only with the tiers

immediately on either side of it; a tier is not aware of the existence of other tiers in the system

apart from its neighbors


Multi-tier Architectural Style


Application Server

Presentation

Business Logic

Data Access

DBMS

Tables/Triggers/Stored procedures

Client

Browser Internet

Multi-tier style: Common Tiers Common tiers in business software systems include the

following:

1. Client (usually thin client - browser)

2. Application Server; is responsible for:

1. Presentation (user interface preparation; e.g. HTML generation)

2. Business processes (combining a sequence of business transactions into a service)

3. Business transactions/Application Services (the fundamental business operations in the system that act on business entities)

4. Data Access

3. Data Storage (the databases in which the data resides)


Multi-tier style: Consequences Advantages:

Clear separation of concerns between tiers

Disadvantages:

Overhead of communication via computer network between the tiers


Layers Architectural Style The layers architectural pattern helps to structure

applications that:

can be decomposed into groups of subtasks in which

each group of subtasks is at a particular level of abstraction


Layers style: Example: ISO OSI


Layers style: Context and Problem Context: A large system that requires decomposition

Problem: need to balance the following forces: Late source code changes should not ripple through the

system. They should be confined to one component and not affect others

Interfaces should be stable and may even be prescribed by a standards body

It may be necessary to build other systems at a later date with the same low-level issues as the system you are currently designing

Complex components need further decomposition


Layers style: Solution


Layers style: Solution


Layers style: Known Uses Virtual Machines: JVM, CLR

Operating Systems: Windows NT layers:

System services

Resource management layer

Kernel

HAL (Hardware Abstraction Layer)

Hardware


Layers style: Known Uses


Business software systems often have following layers:

Layers style: Consequences Benefits:

Reuse of layers

Support for standardization

Dependencies are kept local

Liabilities:

Cascades of changing behavior

Lower efficiency

Difficulty of establishing the correct granularity of layers


Layers style: Do not confuse with Multi-tier style! Layers are concerned with the logical division of

components and functionality, and DO NOT take into account the physical location of components,

Tiers describe the physical distribution of the functionality and components on separate servers, computers, networks, or remote locations Tiers always communicate via computer network!

Tiers are often visualized as running horizontally, while layers are often visualized as running vertically.

The two styles are often combined, with each tier in the system using a stack of layers within it to organize its implementation into different levels of abstraction


Publisher/Subscriber Architectural Style The Publisher/Subscriber design pattern helps to keep

the state of cooperating components synchronized.

To achieve this it enables one-way propagation of changes: one publisher notifies any number of subscribers about changes to its state

A single type of connector, a reliable network link, is used to link the publisher and the subscribers

Also known as: Observer pattern

Yet pattern assumes in-process communication


Publisher/Subscriber style: Problem Solution should balance the following forces:

One or more components must be notified about state changes in a particular component.

The number and identities of dependent components is not known a priori, or may even change over time.

Explicit polling by dependents for new information is not feasible.

The information publisher and its dependents should not be tightly coupled when introducing a change-propagation mechanism.


Publisher/Subscriber style: Solution One dedicated component takes the role of the publisher.

All components dependent on changes in the publisher are its subscribers.

The publisher maintains a registry of currently-subscribed components.

Whenever a component wants to become a subscriber it uses the subscribe interface offered by the publisher. Analogously, it can unsubscribe.

Whenever the publisher changes state, it sends a notification to all its subscribers. The subscribers in turn: receive the changed data as part of notification (push model)

retrieve the changed data at their discretion (pull model)


Publisher/Subscriber style: Consequences Advantages:

The flexibility to add new subscribers dynamically,

The relatively loose coupling between publisher and subscribers,

The increased efficiency that comes from the subscribers not having to poll the publisher repeatedly to find new and changed information.

Disadvantages: The main disadvantage of the style is its relatively

complex implementation if reliable delivery of messages is required.


Publisher/Subscriber style: Examples Inter-system communication

Java Messaging System (JMS), MSMQ (Microsoft Message Queue)

Event driven communication

CDI Events, Spring Framework Events


Model-View-Controller Architectural Style The Model-View-Controller architectural style (MVC)

divides an interactive application into three components:

The model contains the core functionality and data.

Views display information to the user.

Controllers handle user input.

Views and controllers together comprise the user interface

A change-propagation mechanism ensures consistency between the user interface and the model


MVC style: Context and Problem Context: Interactive applications with a flexible

human-computer interface

Problem: The following forces influence the solution: The same information is presented differently in

different windows, for example, in a bar or pie chart.

The display and behavior of the application must reflect data manipulations immediately.

Changes to the user interface should be easy.

Supporting different 'look and feel' standards or porting the user interface should not affect code in the core of the application.


MVC style: Solution The model component encapsulates core data and

functionality. The model is independent of specific output representations or input behavior.

View components display information to the user. A view obtains the data from the model. There can be multiple views of the model.

Each view has an associated controller component. Controllers receive input, usually as events that encode mouse movement, activation of mouse buttons, or keyboard input. Events are translated to service requests for the model or the view. The user interacts with the system solely through controllers.


MVC style: Solution


MVC style: Typical Interaction


MVC style: Consequences Benefits:

Multiple views of the same model Synchronized views 'Pluggable' views and controllers Exchangeability of 'look and feel‘ Framework potential

Liabilities: Increased complexity Potential for excessive number of updates

There exist alternative styles, for example: Presentation-Abstraction-Control, Model-View-Presenter, etc. Interactive Application Architecture Patterns


http://aspiringcraftsman.com/2007/08/25/interactive-application-architecture/

Broker Architectural Style Description: The Broker architectural pattern can be

used to structure distributed software systems with decoupled components that interact by remote service invocations.

A broker component is responsible for coordinating communication, such as forwarding requests as well as for transmitting results and exceptions.

Context: Distributed and possibly heterogeneous system with independent cooperating components


Broker style: Problem Need to balance the following forces:

Components should be able to access services provided by others through remote, location-transparent service invocations.

You need to exchange, add, or remove components at run-time.

The architecture should hide system- and implementation-specific details from the users of components and services.


Broker style: Solution The Broker architectural pattern comprises six types of

participating components: clients, servers, brokers, client-side proxies, server-side proxies and bridges.

A server implements objects that expose their functionality through interfaces that consist of operations and attributes.

Clients are applications that access the services of at least one server. To call remote services, clients forward requests to the broker. After an operation has executed they receive responses or exceptions from the broker.

Servers may also act as clients


Broker style: Solution


Broker style: Solution A broker is a messenger that is responsible for the

transmission of requests from clients to servers, as well as the transmission of responses and exceptions back to the client

A broker must have some means of locating the receiver of a request based on its unique identifier A broker offers APIs to clients and servers that include

operations for registering servers and for invoking server methods

When a request arrives for a server that is maintained by the local broker, the broker passes the request directly to the server

If the specified server is hosted by another broker, the local broker finds a route to the remote broker and forwards the request using this route


Broker style: Solution Client-side/Server-side proxies represent a layer between

clients and the broker.

This additional layer provides transparency, in that a remote object appears to the client as a local one

Proxies perform marshaling of parameters and results

Bridges are optional components used for hiding implementation details when two brokers interoperate.

Suppose a Broker system runs on a heterogeneous network. If requests are transmitted over the network, different brokers have to communicate independently of the different network infrastructures and operating systems in use


Broker style: Consequences Benefits:

Location Transparency

Changeability and extensibility of components

Interoperability between different Broker systems

Liabilities:

Restricted efficiency

Lower fault tolerance


Broker style: Known Uses Distributed Objects:

CORBA - Common Object Request Broker Architecture

is used by EJB for remote communication

Microsoft DCOM

Java RMI (Remote Method Invocation)

SMTP servers (they communicate as brokers)

Enterprise Service Bus (ESB)


Hierarchy of Patterns Applying an architectural style/pattern we are

decomposing system to some structural elements

The resulting elements might organize their internal structure according to some (other) architectural style/pattern too

This “recursion” might be repeated several times –number of repetitions depends on the system’s size

As a result we get hierarchy of patterns



Example: Patterns applied hierarchically

Example: Hierarchy of Patterns


Multi-tier (Client, AS, Data

Storage)

Thin clientLayers

(UI, BL, DA)

MVCCOP, SoC, Loose Coupling, DRY

ORM/Active Record/Data

Mapper, Locking strategies

OLTP+ACID

Application Archetypes Some architectural style hierarchies are commonly

found in software systems

We often hear “Web-based system”, “Desktop application”, and so on.

Definition: An archetype is a primordial thing or circumstance that recurs consistently and is thought to be a universal concept or situation

Definition (simplified): An application archetype is a collection of architectural styles that occurs consistently and universally in software systems


Common Archetypes(Book “Microsoft® Application Architecture Guide”, 2009; HTML version)

Web applications - Applications of this type typically support connected scenarios and can support different browsers running on a range of operating systems and platforms

Rich client applications (aka Desktop application) - stand-alone applications with a graphical user interface that displays data using a range of controls

Rich Internet applications - Applications supporting multiple platforms and multiple browsers, displaying rich media or graphical content.

Mobile applications - thin client or rich client applications. Rich client mobile applications can support disconnected or occasionally connected scenarios. Web or thin client applications support connected scenarios only. Device resources may prove to be a constraint when designing mobile applications

Service applications - Services expose shared business functionality and allow clients to access them from a local or a remote system. Service operations are called using messages, based on XML schemas, passed over a transport channel.


http://msdn.microsoft.com/en-us/library/ff650706.aspx

Web Application Archetype(Book “Microsoft® Application Architecture Guide”, 2009; HTML version)

The core of a Web application is its server-side logic.

This logic may be comprised of many distinct layers



Rich Internet Application Archetype(Book “Microsoft® Application Architecture Guide”, 2009; HTML version)

Rich UI Engine:

Flash

JavaFX

Silverlight, etc.

The benefits of a RIA over traditional Web applications include richer user experience, improved user responsiveness, and improved network efficiency



Other Patterns Data/information management:

CRUD

CQRS

Event Sourcing

Concurrency patterns


Patterns Architectural Styles Archetypes - VUdonatas/PSArchitekturaProjektavimas...Patterns The purpose of a pattern is to share a proven, widely applicable solution to a particular

Documents