Software Life-Cycle Management

(1)

Software Life-Cycle Management

Architecture Styles

Department Computer Science University of Basel

Theory

(2)

Department of Computer Sciences – University of Basel 2

Architecture Styles

Overview

 An Architecture Style expresses a fundamental structural organization schema for software systems

 An Architectural Style …

• provides a set of predefined element types

• specifies their responsibilities

• includes rules and guidelines for organizing the relationships between them

 There is some overlap between Architecture Styles and Patterns

(3)

Architecture Styles

Benefits

 Architecture Styles – similar to Patterns – are …

• A store of knowledge

- Patterns are a store of knowledge about solving a particular type of problem in a particular domain

- Documenting this knowledge allows it to be shared among people solving similar problems

- People can move between specialist areas more easily and work more effectively within a particular area by sharing knowledge about success and failure

• Examples of good practices.

- A set of patterns provides examples of good design practices

- You can use these examples directly and re-apply them within your given context

• A language

- Patterns allow designers to create and share a common language for discussing design problems

- This common language helps designers relate ideas to each other easily and analyze alternative solutions to a problem

- This allows for more effective communication among participants in the design process

(4)

Architecture Styles

Benefits

 Architecture Styles – similar to Patterns – are …

• An aid to standardization

- The use of patterns encourages designers to choose standard solutions to recurring problems rather than searching for novel solutions in each case

- This has obvious efficiency benefits for the design process, and reliability is also likely to increase because of the reuse that results from the application of an already proven solution

• Encouragement of generality

- Good patterns are usually generic, flexible, and reusable in a number of situations - Providing flexible and generic solutions to problems is often a goal for architects as

well

- Using patterns as inputs to the design process and thinking in terms of identifying design patterns within the design process can help you create flexible, generic solutions to the problems within your system

(5)

Architecture Styles

Pipes & Filters Architecture Style

 Pipes and Filters

• The Pipes and Filters style is characterized by a single, simple element type (the filter) that processes a data stream, with instances of this type connected by simple connectors known as pipes

• Example of Use. A few examples follow

• Advantages. The style allows filter implementation to easily be changed

without affecting other system elements, and it makes creating new pipelines by recombining existing filters easy. Parallel processing can also be supported with multiple filters running concurrently

• Disadvantages. Sharing state information is difficult with this style, and the data transformation required for a common interfilter data format adds

overhead. Error handling is difficult and needs to be implemented consistently down the pipeline

• Common Variants. Pipes can execute in parallel rather than in sequence, or filters can have more than one entrance or exit channel.

(6)

Architecture Styles

Pipes & Filters Architecture Style

 Pipes and Filters (continued)

• In Unix System the Pipes and Filters style is the pre-dominant model for Shell programming

(7)

Architecture Styles

Pipes & Filters Architecture Style

 Pipes and Filters (continued)

• In Unix System the Pipes and Filters style is the pre-dominant model for Shell programming

(8)

Architecture Styles

Pipes & Filters Architecture Style

 Pipes and Filters (continued)

• The “Chain of Responsibility” Pattern conceptually outlines the static model this style is based upon

(9)

Architecture Styles

Pipes & Filters Architecture Style

 Pipes and Filters (continued)

• Also Workflow Systems are often using this pattern as their underlying organisation schema

(10)

Architecture Styles

Pipes & Filters Architecture Style

 Pipes and Filters (continued)

(11)

Architecture Styles

Pipes & Filters Architecture Style

 Pipes and Filters (continued)

(12)

Architecture Styles

Pipes & Filters Architecture Style

 Pipes and Filters (continued)

• Also EAI or ESB types of Systems use Pipes and Filters as their internal means of abstracting …

- Processing nodes (Filters)

- Connectors between these (Pipes)

(13)

Architecture Styles

Client / Server Architecture Style

 Client / Server

• This very widely used style defines a system structure comprised of two types of elements

- A server that provides one or more services via a well-defined interface - A client that uses the services as part of its operation

• The client and server are typically assumed to reside on different machines in a network (although this is not a requirement)

• Example of Use. This style is probably very familiar to you from mainstream IT technologies such as client/server databases

• Advantages. The advantages of the style include the centralization of complex or sensitive processing

• Disadvantages. Making the request and receiving the response between clients and servers that do not reside on the same machine introduces some unavoidable inefficiency

• Common Variants.

- Stateful Server (where the server is responsible for tracking of conversational state) - Stateful Client, Stateless Server (where the client is responsible for conv. state)

(14)

Architecture Styles

Client / Server Architecture Style

 Client / Server (continued)

(15)

Architecture Styles

Tiered Computing Architecture Style

 Tiered Computing

• A development of the Client/Server style

• The Tiered Computing style is widely used in enterprise information systems

• A tiered system is considered to contain a number of tiers of 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

• Common tiers in enterprise information systems include the following

- Client

- Presentation - Business Logic - Integration

- Database & Persistence Systems

(16)

Architecture Styles

Tiered Computing Architecture Style

 Tiered Computing (continued)

• Example of Use. Most large enterprise information systems are organized into tiers, and a number of common application development technologies (such as J2EE and .NET) encourage this organization

• Advantages. This style allows a clear separation of concerns between tiers and provides the potential for reusability of the simpler tiers (data storage, data access, and business transactions) across a number of systems

• Disadvantages. Disadvantages of the style include the overhead of

communication between the tiers and additional development complexity arising from the number of system elements that need to be developed and integrated across the tiers

(17)

Architecture Styles

Tiered Computing Architecture Style

 Tiered Computing (continued)

(18)

Architecture Styles

Peer-to-Peer Architecture Style

 Peer-to-Peer

• Often referred to as P2P, this architectural style defines

- a single type of system element (the peer)

- a single type of connector that is a network connection (an interpeer connection)

• The characteristics of the connector are not important to the style, and the style has been used with a number of types of network connections

• The central organizational principle of the system is that any peer is free to communicate directly with any other peer, without needing to use a central server

• Peers typically locate each other by automatically exchanging lists of known peers

• Each peer is capable of acting as both client (when making requests) and server (when servicing requests), often being both concurrently.

(19)

Architecture Styles

Peer-to-Peer Architecture Style

 Peer-to-Peer (continued)

• Example of Use. Well-known examples of the P2P style include Internet file- swapping applications and distributed computation systems

• Advantages. P2P systems eliminate the possible point of failure that a central server represents, can be made very scalable, and are resilient to partial

failures in the underlying network

• Disadvantages. Disadvantages of P2P systems include the possible

partitioning of the network if no central peer list is available and the difficulty of guaranteeing a particular response from the system at any point in time

(20)

Architecture Styles

Peer-to-Peer Architecture Style

 Peer-to-Peer (continued)

(21)

Architecture Styles

Layered Implementation Architecture Style

 Layered Implementation

• The Layered Implementation style identifies a single type of system element

- the layer

• The style organizes a system's implementation into a stack of layers, with each layer providing a service to the layer above it and requesting services from the one below it

• The layers are ordered by the level of abstraction they represent, with the most abstract (e.g., organization-specific operations) at the top of the stack and the least abstract (e.g., operating system – specific libraries) at the bottom

• Depending on the implementation of the style, a layer may be able to

communicate directly with any of the layers below it (relaxed layering) or only with the layer directly below it (strict layering)

(22)

Architecture Styles

Layered Implementation Architecture Style

 Layered Implementation (continued)

• Example of Use. Communication stacks are the classic example of layered organization, but most information system technologies are organized in this way too (e.g., a locally developed utility library layered above a third-party library layered above the operating system)

• Advantages. Likely advantages of this style of organization include the reuse of layers, good separation of concerns, and relatively easy maintenance due to the isolation of each layer's implementation

• Disadvantages. Disadvantages include a reduction in implementation

flexibility, a reduction in efficiency when many layers need to be traversed, and the constraints that the style places on the development process (layers often need to be developed in order)

(23)

Architecture Styles

Layered Implementation Architecture Style

 Layered Implementation (continued)

(24)

Architecture Styles

Layered Implementation Architecture Style

 Layered Implementation (continued)

• Layers can be contrasted with the tiers in the Tiered Computing style because layers are organized based on the level of abstraction they deal with, whereas tiers are organized based on the type of service they provide

• All of the layers in a particular implementation are concerned with providing a single service, but each layer is concerned with a different level of abstraction involved in providing the service

• In contrast, the tiers in an implementation all operate at a broadly similar level of abstraction but are each concerned with providing a different type of service, which, when the services are combined, creates a useful system

• Given this difference, tiers are often visualized as running horizontally, while layers are often visualized as running vertically

• Indeed, 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

(25)

Architecture Styles

Layered Implementation Architecture Style

 Layered Implementation (continued)

(26)

Architecture Styles

Publisher/Subscriber Architecture Style

 Publisher/Subscriber

• The Publisher/Subscriber style grew out of a realization that client/server interactions are not suitable for all types of distributed system problems

• The style defines

- a single system element (the publisher) that creates information of interest to - any number of system elements (the subscribers) that may wish to consume it

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

• The subscribers register their interest in certain information with the publisher

• When the publisher creates or changes information that subscribers have

registered their interest in, the publisher notifies the relevant subscribers of the change

• Depending on the implementation of the style, the notification may contain the new or changed information, or it may just be a notification of a relevant

change, leaving the subscribers to query the publisher for changes themselves

(27)

Architecture Styles

Publisher/Subscriber Architecture Style

 Publisher/Subscriber (continued)

• Example of Use. The Publisher/Subscriber style is widely implemented in enterprise messaging systems

• Advantages. Advantages include the flexibility to add new subscribers

dynamically, the relatively loose coupling between publisher and subscribers, and 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 (particularly if reliable delivery of messages is required)

(28)

Architecture Styles

Publisher/Subscriber Architecture Style

 Publisher/Subscriber (continued)

(29)

Architecture Styles

Asynchronous Data Replication Architecture Style

 Asynchronous Data Replication

• Asynchronous Data Replication, is a style used where information in two data stores needs to be kept synchronized

• The style has three element types …

- Data source. A data store that owns a particular type of information

- Data replica. Separate data store that wishes to maintain a synchronized copy of some subset of the information in the source

- Replicator. Element responsible for recognizing changes or additions to information in the source and performing the synchronization of the replica data store

(30)

Architecture Styles

Asynchronous Data Replication Architecture Style

 Asynchronous Data Replication (continued)

• Example of Use. This style is widely implemented in enterprise data replication technologies, such as those supplied by the major database vendors

• Advantages. The advantages of the style include the ability to synchronize two data stores automatically and efficiently, without needing to complicate the

application logic

• Disadvantages. Common problems include the latency that can occur

between source update and replica update as well as the complexity of dealing with updates at the replica data store

(31)

Architecture Styles

Asynchronous Data Replication Architecture Style

 Asynchronous Data Replication (continued)

(32)

Architecture Styles

Integration Hub Architecture Style

 Integration Hub

• The Integration Hub style is another data-oriented architectural style, extending Asynchronous Data Replication to situations where information needs to be synchronized between a number of different systems (rather than between replica data stores)

• This style defines four types of system elements

- Data source - Data destination - Hub

- Adapter

• The elements are organized into a cartwheel form, with the hub at the center of the wheel and the data sources and destinations at the outer edges of the

spokes

• Along every spoke, between hub and source or destination is an adapter (so each spoke is an adapter connected to a source or destination, radiating out from the hub)

(33)

Architecture Styles

Integration Hub Architecture Style

 Integration Hub (continued)

• Example of Use. This style is widely implemented by EAI products that allow data integration between applications

• Advantages. Integration Hub allows new data sources and destinations to be added easily to the system without disrupting the existing implementation. It can also integrate sources and destinations of practically any form because a dedicated adapter hides the specifics of a source or destination

• Disadvantages.

- Data movement between applications will be relatively inefficient due to the amount of translation, and the imposition of a common model may mean that some information that the common model does not accommodate is lost in translation

- The design of the common model can also be quite difficult

- The hub itself can become a central point of failure or a performance bottleneck if it is not designed properly

- This risk can be mitigated to some extent by extending the cartwheel topology into a snowflake which links multiple hubs together