Software Life-Cycle Management

Transcription

1 Ingo Arnold Department Computer Science University of Basel Theory Software Life-Cycle Management Architecture Styles

2 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 Department of Computer Sciences University of Basel 2

3 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 Department of Computer Sciences University of Basel 3

4 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 Department of Computer Sciences University of Basel 4

5 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. Department of Computer Sciences University of Basel 5

6 Pipes & Filters Architecture Style Pipes and Filters (continued) In Unix System the Pipes and Filters style is the pre-dominant model for Shell programming Department of Computer Sciences University of Basel 6

7 Pipes & Filters Architecture Style Pipes and Filters (continued) In Unix System the Pipes and Filters style is the pre-dominant model for Shell programming Department of Computer Sciences University of Basel 7

8 Pipes & Filters Architecture Style Pipes and Filters (continued) The Chain of Responsibility Pattern conceptually outlines the static model this style is based upon Department of Computer Sciences University of Basel 8

9 Pipes & Filters Architecture Style Pipes and Filters (continued) Also Workflow Systems are often using this pattern as their underlying organisation schema Department of Computer Sciences University of Basel 9

10 Pipes & Filters Architecture Style Pipes and Filters (continued) Also Workflow Systems are often using this pattern as their underlying organisation schema Department of Computer Sciences University of Basel 10

11 Pipes & Filters Architecture Style Pipes and Filters (continued) Also Workflow Systems are often using this pattern as their underlying organisation schema Department of Computer Sciences University of Basel 11

12 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) Department of Computer Sciences University of Basel 12

13 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) Department of Computer Sciences University of Basel 13

14 Client / Server Architecture Style Client / Server (continued) Department of Computer Sciences University of Basel 14

15 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 Department of Computer Sciences University of Basel 15

16 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 Department of Computer Sciences University of Basel 16

17 Tiered Computing Architecture Style Tiered Computing (continued) Department of Computer Sciences University of Basel 17

18 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. Department of Computer Sciences University of Basel 18

19 Peer-to-Peer Architecture Style Peer-to-Peer (continued) Example of Use. Well-known examples of the P2P style include Internet fileswapping 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 Department of Computer Sciences University of Basel 19

20 Peer-to-Peer Architecture Style Peer-to-Peer (continued) Department of Computer Sciences University of Basel 20

21 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) Department of Computer Sciences University of Basel 21

22 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) Department of Computer Sciences University of Basel 22

23 Layered Implementation Architecture Style Layered Implementation (continued) Department of Computer Sciences University of Basel 23

24 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 Department of Computer Sciences University of Basel 24

25 Layered Implementation Architecture Style Layered Implementation (continued) Department of Computer Sciences University of Basel 25

26 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 Department of Computer Sciences University of Basel 26

27 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) Department of Computer Sciences University of Basel 27

28 Publisher/Subscriber Architecture Style Publisher/Subscriber (continued) Department of Computer Sciences University of Basel 28

29 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 Department of Computer Sciences University of Basel 29

30 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 Department of Computer Sciences University of Basel 30

31 Asynchronous Data Replication Architecture Style Asynchronous Data Replication (continued) Department of Computer Sciences University of Basel 31

32 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) Department of Computer Sciences University of Basel 32

33 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 Department of Computer Sciences University of Basel 33

34 Integration Hub Architecture Style Integration Hub (continued) Department of Computer Sciences University of Basel 34

35 Questions? Department of Computer Sciences University of Basel 35