3 - architetture software - architectural styles
DESCRIPTION
TRANSCRIPT
Paolo Ciancarini
Architectural styles
2
Agenda Types of architectural styles Basic decomposition techniques
layering, tiering
Architectural styles Pipes and filters Repository Client/Server
two-tiers; three-tiers; n-tiers Model/View/Controller Service-Oriented Peer-To-Peer
3
Layers and tiers The architectural definition of a system is generally
achieved by decomposing the architecture into subsystems, following a layered and/or a partition based approach (tiers)
These are orthogonal approaches: A layer is a level in an architectural stack in charge of
providing services (e.g., a kernel) A tier is the organization of several peer modules within
the same layer (e.g., a user interface)
4
Layers An architecture which has a hierarchical structure,
consisting of an ordered set of layers, is layered A layer is a set of subsystems which are able to provide
related services, that can be realized by exploiting services from other layers
A layer depends only from its lower layers (i.e., layers which are located at a lower level into the architecture) A layer is only aware of lower layers
Layers of virtual machines
5
Layers: component diagram Connectors for layered systems
are often procedure calls Each level implements a
different VM with a specific input language
6
Closed vs open layers Closed architecture: the i-th layer can only have
access to the layer (i-1)-th Open architecture: the i-th layer can have access
to all the underlying layers (i.e., the layers lower than i)
7
8
Layers – Closed architecture The i-th layer can only invoke the services and the
operations which are provided by the layer (i-1)-th The main goals are the system maintainability and
high portability (eg. Virtualization: each layer i defines a Virtual Machine - VMi)
VM4
VM3
VM2
VM1 C1
attr op
C1 attr op
C1 attr op
C1 attr op
C1 attr op
C1 attr op
C1 attr op
C1 attr op
C1 attr op
9
Closed layers: ISO/OSI stack
The ISO/OSI reference model defines 7 network layers, characterized by an increasing level of abstraction Eg. The Internet Protocol (IP) defines a VM at the network level able to identify net hosts and transmit single packets from host to host
Application
Presentation
Session
Transport
Network
DataLink
Physical
Leve
l of a
bstra
ctio
n
10
Layers – Open architecture The i-th layer can invoke the services and the
operations which are provided by all the lower layers (the layers lower than i)
The main goals are the execution time and efficiency
C1 attr op
C1 attr op
C1 attr op
C1 attr op
C1 attr op
C1 attr op
C1 attr op
C1 attr op
C1 attr op
Xlib
Xt
Motif
Application Open layers: OSF/Motif
Xlib provides low-level drawing facilities; Xt provides basic user interface widget management; Motif provides a large number of sophisticated widgets; The Application can access each layer independently
Creating layers: façade
12
Creating layers: façade
13
14
Tiers Another approach to managing complexity consists
of partitioning a system into sub-systems (peers), which are responsible for a class of services
15
Typical tiered architecture
16
4 tiers architecture
17
Layers and tiers Typically, a complete decomposition of a given
system comes from both layering and partitioning First, the system in divided into top level subsystems
which are responsible for certain functionalities (partitioning)
Second, each subsystem is organized into several layers, if necessary, up to the definition of simple enough layers
18
19
Architectural styles Several architectural styles have been defined in
the literature of software engineering. They can be used as the basis for configuring
software architectures. The basic styles include:
Pipes and filters Repository Client/Server: two-tiers; three-tiers; n-tiers Model/View/Controller Service-Oriented Peer-To-Peer
Architectural variants
Pipes and Filters style
Pipe and Filter Architecture
Main components: Filter: process the a stream of input data to some out
put data Pipe: a channel that allows the flow of data
read input file process file
filter
pipe
This architecture style focuses on the dynamic (interaction) rather than the structural
Batch sequential data flow
23
222 U 111 I 333 D -123 U
Validate 222 U 111 I 333 D
sort111 I 222 U 333 D
Update100 ----111 ----200 ----222 ----444 ----
100 ---200 ---222 ---333 ---444 ---
Generate Report
Sortedtransaction
Validated transaction
Updated Master file
Rejected transaction
-123 U
Master file
Reports
Transaction File
Pipe and Filter : UNIX shell UNIX shell command line processing of the pipe symbol: “l”
the output from the command to the left of the symbol, l, is to be sent as input to the command to the right of the pipe;
this mechanism got rid of specifying a file as std output of a command and then specifying that same file as the std input to another command, including possibly removing this intermediate file afterwards
Example : counting occurrences in a file I have a mailinglist file called “swarch.txt” cat swarch.txt | grep studio | wc
Note the pipe symbol, l
More Modern Version of Pipe-filter
Consider the MS Office Product
Specifically --- think about how the component called “copy” works in conjunction with the component called “paste” across office product (e.g. spread sheet to word document )
The clipboard as a “pipe”
How may this be extended to the way e-mail with file attachment work?
Pipe-Filter example
The high level design solution is decomposed into 2 parts (filters and pipes): Filter is a service that transforms a stream of input data into a stream of
output data Pipe is a mechanism or conduit through which the data flows from one
filter to another
Input time cards
Prepare for Check processing Process Checks
Problems that require batch file processing seem to fit this: payroll and compilers
Pipe – Filter with error processing
Even if interactive error processing is difficult, batch error processing can be done with a pipe and filter architecture
Input time cards
Validate for payroll processing
Automatically Process Checks
Manually Reprocess Card and Cut Check
Payroll report Do the data streams need to be synchronized here for report?
Splitting the good time cards from the bad ones
Pipes and filters Pipe: communication channel Filter: computing component
Filter 1 may only send data to Filter 2 Filter 2 may only receive data from Filter 1 Filter 1 may not receive data Filter 2 may not send data Pipe is the data transport mechanism
Filter 1 (Source)
Filter 2 (Sink)
Pipe
Pipe input output
output input * 1
* 1
Filter
+Read() +Write()
Pipe and Filter Class Diagram
Filter+Read()+Write()
Pipe
+read()
Data Source
+write()
Data Sink
Pipe and Filter Sequence Diagram
data source:Data Source
filter1:Filter
pipe:pipe
filter2:Filter
data sink:Data Sink
R
write
W
read
Filter1
Data Source Filter1 Filter2 Data Sink
pipe
Filter2
Data flow types There are three ways to make the data flow:
Push only (Write only) A data source may pushes data in a downstream A filter may push data in a downstream
Pull only (Read only) A data sink may pull data from an upstream A filter may pull data from an upstream
Pull/Push (Read/Write) A filter may pull data from an upstream and push
transformed data in a downstream
Active or passive filters An active filter pulls in data and push out the transformed
data (pull/push); it works with a passive pipe which provides read/write mechanisms for pulling and pushing. The pipe & filter mechanism in Unix adopts this mode. The PipedWriter and PipedReader classes in Java are also passive
pipes that active filters must use to drive the data stream forward
A passive filter lets connected pipes to push data in and pull data out. It works with active pipes that pull data out from a filter and push data into the next filter. The filter must provide the read/write mechanisms in this case. This is very similar to the data flow hardware architecture
Pipe and Filter Sequence Diagram
data source Filter 1 Pipe Filter 2 data sink
Read
Read Read
Write
Write
Read
Write
Read
( blocking )
active Pull /push
passive Pull /push Push only Pull only
active Pull /push
“Architectural” package diagram
34
<<metaclass>> Component
<<metaclass>> Connector
<<stereotype>> Filter
<<stereotype>> Pipe
UML
Pipes&filters
Component diagram
35
<<filter>> <<component>>
pic
<<filter>> <<component>>
eqn
<<pipe>> <<pipe>>
<<filter>> <<component>>
tbl
<<filter>> <<component>>
troff
<<pipe>> <<pipe>> <<pipe>> <<pipe>> <<pipe>> <<pipe>>
Pipes and Filters: pro and cons
Advantages: Filters are self containing processing services that perform a
specific function thus the style is cohesive Filters communicate (pass data most of the time) through pipes
only, thus the style results in low coupling
Disadvantages: The architecture is static (no dynamic reconfiguration) Filter processes which send streams of data over pipes is a
solution that fits well with heavy batch processing, but may not do well with any kind of user-interaction.
Anything that requires quick and short error processing is still restricted to sending data through the pipes, possibly making it difficult to interactively react to error-events.
Repository-based style
Shared Data Very common in information systems where data is shared
among different functions A repository is a shared data-store with two variants:
Repository style: the participating parties check the data-store for changes
Blackboard (or tuple space) style: the data-store alerts the participating parties whenever there is a data-store change (trigger)
Patient database
Physician diagnosis
Pharmacy & drug processing
Lab testing
Accounting & administration
Problems that fit this style have the following properties:
1. All the functionalities work off a shared data-store 2. Any change to the data-store may affect all or some of the functions
3. All the functionalities need the information from the data-store
Repository Architecture
39
Agent 1
Agent 3
Agent 2
Agent n
Agent 4
Repository
Repository Architecture The subsystems use and modify (i.e., they have
access to) a shared data structure named repository
The subsystems are relatively independent, in that they interact only through the repository
Subsystem
Repository
createData() setData() getData() searchData()
41
Example: a compiler architecture based on a repository
LexicalAnalyzer
SyntacticAnalyzer SemanticAnalyzer
CodeGenerator
Compiler
SyntacticEditor
ParseTree SymbolTable
Repository
SourceLevelDebugger
Optimizer
Repository: two flavors Data-centered style supporting user interactions The control flow into the system can be managed
both by the repository (if stored data have to be modified) and by the subsystems (independent control flow)
Passive repository (blackboard, tuple space): agents write or read items in the repository
Active repository: the repository calls registered agents. This can be implemented with publish/subscribe
42
publish/subscribe Agents interact by broadcast or multicast
messages Each agent notifies a state change via a message
(it “raises an event”) All agents interested to the event (“observers”)
receive a copy of the message Event generators do not know the observers
(decoupling) Examplex: device drivers, JavaBeans
43
publish/subscribe
44
Observer pattern
45
Publish subscribe variants
46
Tuple space A tuple space is a repository where agents
(“Workers”) read or write tuples by pattern matching Main primitives:
out(tuple) non blocking, creates new tuple! rd(tuple pattern) blocking, does not delete matching tuple in(tuple pattern) blocking, deletes matching tuple eval(tuple) non blocking, creates new worker
47
48
Repository: pro and cons Benefits
It is an effective way to share huge amounts of data: write once for all to read Each subsystem has not to take care of how data are produced/consumed by
other subsystems It allows a centralized management of system backups, as well as of security
and recovery procedures The data sharing model is available as the repository schema, hence it is
easy to plug new subsystems Pitfalls
Subsystems have to agree on a data model, thus impacting on performance Data evolution: it is “expensive” to adopt a new data model since (a) it has to
be applied on the entire repository, and (b) all the subsystems have to be updated
Not for all the subsystems’ requirements in terms of backup and security are always supported by the repository
It is tricky to deploy the repository on several machines, preserving the logical vision of a centralized entity, due to redundancy and data consistency matters
Client-Server style
Client server
50
remote remote remote
51
Client-server paradigm It has been conceived in the context of distributed
systems, aiming to solve a synchronization issue: A protocol was needed to allow the communication
between two different programs The driving idea is to make unbalanced the
partners’ roles within a communication process Reactive entities (named servers):
They cannot initiate a communication … they can only answer to incoming requests (reactive entities)
Active entities (named clients): They trigger the communication process They forward requests to the servers, then they wait for
responses
52
Client-server paradigm The first generation of distributed systems was
based on the client server style
Mainframe Monolithic
1st Generation Client/Server
2nd Generation Distributed Objects
Complexity & adaptability
Deg
ree
of
dist
ribut
ion
53
Client-server style From the architectural viewpoint, a client/server system
is made up of components which can be classified according to the service abstraction: Who provides services is a server; Who requires a service is a client;
A client is a program used by a user to communicate with a system …but a server can be a client for a different service
Clients are aware of the server interface Servers cannot foresee clients’ requests
Client Server
service1() service2() serviceN()
* * requester! provider!
54
Client-server style Most systems can be logically divided into three parts:
The presentation, which is in charge of managing the user interface (graphic events, input fields check, help..)
The actual application logic The data management tier for the management of persistent data.
The system architecture is defined according to how these parts are organized : 2-tiered, 3-tiered, or n-tiered
Presentation
Application
processing
Data management
55
Client-server style 2 tiers Client/Server architectures
Fat client Fat server
Web has a Client-Server style HTTP (Hypertext Transfer Protocol), ASCII-based request/reply protocol
that runs over TCP HTTPS: variant that first establishes symmetrically-encrypted channel via
public-key handshake, so suitable for sensitive info
By convention, servers listen on TCP port 80 (HTTP) or 443 (HTTPS) Universal Resource Identifier (URI) format: scheme, host, port,
resource, parameters, fragment http://search.com:80/img/search/file?t=banana&client=firefox#p2
Web browser Web server A series of tubes
DNS server
1. 2.
56
A Conversation With a Web Server GET /index.html HTTP/1.0 User-Agent: Mozilla/4.73 [en] (X11; U; Linux 2.0.35 i686) Host: www.yahoo.com Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
image/png, */* Accept-Language: en Accept-Charset: iso-8859-1,*,utf-8
Server replies: HTTP/1.0 200 OK Content-Length: 16018 Set-Cookie: B=2vsconq5p0h2n Content-Type: text/html <html><head><title>Yahoo!</title><base href=http://www.yahoo.com/>
…etc.
Repeat for embedded content (images, stylesheets, scripts...) <img width=230 height=33 src="http://us.a1.yimg.com/us.yimg.com/a/an/anchor/icons2.gif">
HTTP method & URI
Cookie data: up to 4KiB
MIME content type
57
Cookies On first visit to a server, a browser may receive a cookie
from the server in HTTP header Data is arbitrary typically opaque, interpretation is up to the server Usually encrypted, since the client is untrusted
The browser automatically passes appropriate cookie back to server on each request Server may update cookie value with any response Simulates a concept of “session”
Many uses track user’s ID (canonical use: authentication) track session state or a handle to it in Web 1.0, before cookies, “fat URL’s” were used for this
58
59
Two-tier C/S architectures – 1/2 Pitfalls:
Two-tiers C/S architectures exhibit a heavy message traffic since the front-ends and the servers communicate intensively
The business logic is not managed by an ad-hoc component, but is it “shared” by front-end and back-end
client and server depend one from each other It is difficult to reuse the same interface to access different data It is difficult to interact with databases which have different front-
ends The business logic is encapsulated into the user interface
If the logic changes, the interface has to change as well
60
Two-tier C/S architectures – 2/2 Recurrent problem:
Business and presentation logic are not clearly separate E.g., if there is a service which can be accessed by several
devices (e.g., mobile phone, desktop PC) The same logic but different interface
Design pattern: dispatcher Context: a set of servers Problem: A client should not need to know where
servers are located Solution: a dispatcher implementing a naming
service acts as an intermediate layer between clients and servers
61
Client do_task
Server run_service
Dispatcher Location_map locate_Server
request service
establish connection
request connection
62
Three-tier architectures – 1/6 Early 90’s; they propose a clear separation among logics:
Tier 1: data management (DBMS, XML files, …..) Tier 2: business logic (application processing, …) Tier 3: user interface (data presentation and services)
Each tier has its own goals, as well as specific design constraints
No assumptions at all about the structure and/or the implementation of the other tiers , i.e.: Tier 2 does not make any assumptions neither on how data are
represented, nor on how user interfaces are made Tier 3 does not make any assumptions on how business logic works
63
Three-tier architectures – 2/6 Tiers 1 and 3 do not communicate, i.e.:
The user interface neither receives any data from data management, nor it can write data
Information passing (in both the directions) are filterer by the business logic
Tiers work as they were not part of a specific application: Applications are conceived as collections of interacting
components Each component can take part to several applications at
the same time
64
Three-tier architectures – 3/6
65
Three-tier architectures – 4/6 Benefits:
They leverage the flexibility of and the high modifiability of modular systems
Components can be used in several systems A change into a given component do not have any impacts on
the system (apart from changes into the API) It is easier to localize a bug since the system functionalities are
isolated New functionalities can be added to the system by only
modifying the components which are in charge of realizing them, or by plugging new components
66
Three-tier architectures – 5/6 Pitfalls:
Application dimensions and efficiency: Heavy network traffic
High latency for service delivering Ad hoc software libraries have to be used to allow the
communication among components Many LoCs!
Legacy software Many companies make use of preexisting software, monolithic,
systems to manage data Adapters have to be implemented to interoperate with the legacy
SW
67
Three-tier architectures – 6/6 Tiers are logical abstractions, not physical entities
Three-tier architectures can be realized by using only one or two levels of machines
68
N-tier architectures They provide high flexibility Fundamental items:
User Interface (UI): e.g., a browser, a WAP minibrowser, a graphical user interface (GUI)
Presentation logic, which defines what the UI has to show and how to manage users’ requests
Business logic, which manages the application business rules
Infrastructure services The provides further functionalities to the application
components ( messaging, transactions support); Data tier:
Application Data level
Example N-tiers
69
Model/View/Controller style
MVC
71
72
The MVC style Three kinds of subsystems:
Model, which has the knowledge about the application domain - also called business logic
View, which takes care of making application objects visible to system users
Controller, which manages the interactions between the system and it users
Controller
Model
subscriber notifier
initiator
*
repository 1
1
*
View
MVC goal The goal of MVC is, by decoupling models and
views, to reduce the complexity in architectural design and to increase flexibility and maintainability
73
Basic interaction for MVC
74
Initialization for MVC
75
MVC interactions
76
MVC: component diagram example
77
78
MVC Architectures The Model does not depend on any View and/or
Controller Changes to the Model state are communicated to
the View subsystems by means of a “subscribe/notify” protocol (eg. Observer pattern)
MVC is a combination of the repository and three-tiers architectures: The Model implements a centralized data structure; The Controller manages the control flow: it receives
inputs from users and forwards messages to the Model The Viewer pictures the model
79
MVC: An example Two different views of a
file system: The bottom window
visualizes a folder named Comp-Based Software Engineering
The up window visualizes file info related to file named 90DesignPatterns2.ppt
The file name is visualized into three different places
80
MVC: communication diagram 1. Both InfoView and FolderView subscribe the changes to the model File
when created 2. The user enters the new filename 3. The Controller forwards the request to the model 4. The model actually changes the filename and notifies the operation to
subscribers 5. InfoView and FolderView are updated so that the user perceives the
changes in a consistent way
:Controller
:InfoView
:Model
2.User types new filename
1. Views subscribe to event
3. Request name change in model
4. Notify subscribers 5. Updated views
:FolderView
ClientServer 3-tiers vs MVC The CS 3-tiers style may seem similar to the
model-view-controller (MVC) style; however, they are different
A fundamental rule in a 3-tiers architecture is: the client tier never communicates directly with the data tier; all communication must go through the middleware tier: the 3-tiers architecture is linear
Instead, the MVC architecture is triangular: the View sends updates to the Controller, the Controller updates the Model, and the Views get updated directly from the Model
81
MVC vs tiers
82
83
The benefits of the MVC style The main reason behind the separation (Model,
View and Controller) is that the user interfaces (Views) are changed much more frequently than the knowledge about the application domain (Model)
This style is easy to reuse, to maintain, and to extend
The MVC style is especially effective in the case of interactive systems, when multiple synchronous views of the same model have to be provided
Alternatives to MVC
84
Service-Oriented style
(SOA)
A world of services
86
The service-oriented architecture model
87
SOA, web service style (use cases)
88
89
Service-oriented architectures SOAs represent an evolution of client-server
architectures 3rd generation of distributed software systems D
istri
butio
n de
gree
and
mob
ility
2 levels
3 levels
client-server
Complexity
Distributed objects
Distributed components
1st generation 2nd generation 3rd generation
C4 C5
C3 C2 C1
SOAs
90
Service-oriented architectures Service-oriented architecture (SOA) is an
approach to loosely coupled, protocol independent, standards-based distributed computing where a software resource available on the network is considered as a service
SOA is a technology solution that provides an enterprise with the agility and flexibility its users have been looking for
The integration process is based on a composition of services spanning multiple enterprises
91
Service-oriented architectures The following principles define the rules for
development, maintenance, and usage of a SOA: Reuse, granularity, modularity, composability,
componentization, and interoperability Compliance to standards (either cross-industry or
industry-specific) Services identification and categorization, provisioning
and delivery, and monitoring and tracking
Service computing: layered style
92
SOA layers, IBM style
93
94
SOA principles – 1/2 Service encapsulation - Many web-services are
consolidated to be used under the SOA Architecture. Often such services have not been planned to be under SOA
Service loose coupling - Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other
Service contract - Services adhere to a communications agreement, as defined collectively by one or more service description documents
Service abstraction - Beyond what is described in the service contract, services hide logic from the outside world
95
SOA principles – 2/2 Service reusability - Logic is divided into services
with the intention of promoting reuse Service composability - Services can be
coordinated/assembled to form composite services Service autonomy – Services have control over the
logic they encapsulate Service optimization – All else equal, high-quality
services are generally considered preferable to low-quality ones
Service discoverability – Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanisms
96
SOA building blocks – 1/2 Service Consumer (also known as Service
Requestor): it locates entries in the Registry using various find operations and then binds to the service provider in order to invoke one of its services
Service Provider: it creates a service and publishes its interface and access information to the Service registry
Service Registry (also known as Service Broker): it is responsible for making the Service interface and implementation access information available to any potential service requestor
Interaction: State diagram
97
98
SOA building blocks – 2/2 Service registration (provider) and lookup (requestor) in the
registry Service access
Desktop Computer PDA
SERVICE REQUESTOR
SERVICE REGISTRY
SERVICE PROVIDER
Service lookup
Service access
Service registration
Laptop
99
SOA model 1 Service Consumer 2 Service Provider 3 Service Registry 4 Service Contract 5 Service Proxy 6 Service Lease
SOA in UML
100
SOA elements
101
102
SOA characteristics The software components in a SOA are services
based on standard protocols Services in SOA have minimum amount of
interdependencies Communication infrastructure used within an SOA
should be designed to be independent of the underlying protocol layer
Offers coarse-grained business services, as opposed to fine-grained software-oriented function calls
Uses service granularity to provide effective composition, encapsulation and management of services
103
Service granularity Service granularity refers to the scope of
functionality a service exposes Fine-grained services provide a small amount of
business-process usefulness, such as basic data access
Coarse-grained services are constructed from fine-grained services that are intelligently structured to meet specific business needs.
104
Service composition
Jeff Hanson, Coarse-grained Interfaces Enable Service Composition in SOA, JavaOne, August 29, 2003
105
Web Services A W3C standard defining an API accessed via
HTTP and executed on a remote host Definition:
‘A Web service is a software application identified by a URI, whose interfaces and bindings are capable of being defined, described, and discovered as XML artifacts. A Web service supports direct interactions with other software agents using XML based messages exchanged via internet-based protocols.’
Two flavors: big services, RESTful services
106
WS underlying technologies The basic standards for
web services are: XML (Extensible Markup
Language) SOAP (Simple Object
Access Protocol) WSDL (Web Services
Description Language) UDDI (Universal
Description, Discovery and Integration)
107
SOA-related standards XML 1.0 fairly stable, although Schema are in the
process of replacing DTDs (currently Schema 1.1 being worked on).
SOAP 1.2 WSDL 2.0 (coming out, 1.2 current) UDDI version 3 (Aug 2003) BPEL 1.1 (Business Process Execution Language) choreography description language (web services
work flows) started January 2003
108
Web Services Architecture Web Services involve three major roles
Service Provider Service Registry Service Consumer
Three major operations surround web services Publishing – making a service available Finding – locating web services Binding – using web services
Use cases for Web services
109
110
Service publication In order for someone to use your service they have
to know about it To allow users to discover a service it is published
to a registry (UDDI) To allow users to interact with a service you must
publish a description of it’s interface (methods & arguments)
This is done using WSDL
WSDL
111
112
Making a service available Once you have published a description of your
service you must have a host set up to serve it. A web server is often used to deliver services
(although custom application – application communication is also possible).
This functionality has to be added to the web server. In the case of the Apache web server a ‘container’ application (Tomcat) can be used to make the application (servlet) available to Apache (deploying).
113
WS and existing protocols Web services are layered on top of existing, mature
transfer protocols HTTP, SMTP are still used over TCP/IP to pass the
messages Web services (like grids) can be seen as a
functionality enhancement to the existing technologies
114
WS and XML All Web Services documents are written in XML XML Schema are used to define the elements used
in Web Services communication
115
WS and SOAP SOAP is the protocol actually used to communicate
with the Web Service Both the request and the response are SOAP
messages The body of the message (whose grammar is
defined by the WSDL) is contained within a SOAP “envelope”
“Binds” the client to the web service
116
WSDL Describes the Web Service and defines the
functions that are exposed in the Web Service Defines the XML grammar to be used in the
messages Uses the W3C Schema language
117
WS and UDDI UDDI is used to register and look up services with
a central registry Service Providers can publish information about
their business and the services that they offer Service consumers can look up services that are
available by Business Service category Specific service
118
Web Services and SOAs Web Services are an open standards-based way of
creating and offering SOAs Web Services are able to exchange structured
documents that contain different amounts of information, as well as information about that information, known as metadata
In other words, Web Services can be coarse grained. Such coarse granularity is one of the most important features of SOAs
119
Re-architecture to SOA: benefits Provides location independence: Services need not be associated with
a particular system on a particular network Protocol-independent communication framework renders code
reusability Offers better adaptability and faster response rate to changing business
requirements Allows easier application development, run-time deployment and better
service management Loosely coupled system architecture allows easy integration by
composition of applications, processes, or more complex services from other less complex services
Provides authentication and authorization of Service consumers, and all security functionality via Services interfaces rather than tightly-coupled mechanisms
Allows service consumers (ex. Web Services) to find and connect to available Services dynamically
120
Why not SOA For a stable or homogeneous enterprise IT
environment, SOA may not be important or cost effective to implement
If an organization is not offering software functionality as services to external parties or not using external services, which require flexibility and standard-based accessibility, SOA may not be useful
SOA is not desirable in case of real time requirements because SOA relies on loosely coupled asynchronous communication
Cloud computing Software as a service, like Web services Platform as a service, like mashups Infrastructure as a service (or hardware as a
service)
121
Peer-to-peer style
P2P
123
Peer-to-peer architectures They can be considered a generalization of the
client/server architecture Each subsystem is able to provide services, as
well as to make requests Each subsystem acts both as a server and as a client
Peer
service1() service2()
serviceN() …
requester
provider
*
*
124
Peer-to-peer architectures In such an architecture, all nodes have the same
abilities, as well as the same responsibilities. All communications are (potentially) bidirectional
The goal: To share resources and services (data, CPU cycles,
disk space, …) P2P systems are characterized by:
Decentralized control Adaptability Self-organization and self-management capabilities
125
Peer-to-peer architectures Typical functional characteristics of P2P systems
File sharing system File storage system Distributed file system Redundant storage Distributed computation
Typical non-functional requirements Availability Reliability Performance Scalability Anonymity
126
P2P architectures: brief history Although they were proposed 30 years ago, they
mainly evolved in the last decade File sharing systems contributed to increase the
interest (Napster, 1999; Gnutella, 2000) In 2000, the Napster client was downloaded by 50
millions users Traffic peak of 7 TB in a day
Gnutella followed Napster’s footprint The first release was delivered in 2003 In June 2005, Gnutella's population was 1.81 million
computers; in 2007, it was the most popular file sharing network with an estimated market share > 40%
Host servers are listed at gnutellahost.com
127
The phases of a P2P application A P2P application is organized in three phases:
Boot, during which a peer connects to the network and actually performs the connections (P2P boot is rare)
Lookup, during which a peer looks for a provider of a given service or information (generally providers are SuperPeers)
Resource sharing, during which requested resources are delivered, usually in several segments
128
P2P classification – 1/2 P2P applications can be categorized as follows:
Pure P2P applications All the phases are based on P2P
P2P applications lookup and resource sharing are performed according to the P2P
paradigm; Some servers are used to make the boot
Hybrid P2P applications : The resource sharing is performed according to the P2P
paradigm Some servers are used to make the boot; Specific peers are used to perform lookup.
129
P2P classification – 2/2 With respect to lookup phase:
Centralized Lookup Centralized index of providers
Decentralized Lookup Distributed index
Hybrid Lookup Several centralized systems which are linked
into a decentralized system
Napster
Gnutella (original)
Gnutella
132
Gnutella: search
133
Gnutella: reply
134
Skype
Skype A mixed client-server and peer-to-peer architecture addresses
the discovery problem Replication and distribution of the directories, in the form of
supernodes, addresses the scalability problem and robustness problem encountered in Napster
Promotion of ordinary peers to supernodes based upon network and processing capabilities addresses another aspect of system performance: “not just any peer” is relied upon for important services
A proprietary protocol employing encryption provides privacy for calls that are relayed through supernode intermediaries
Restriction of participants to clients issued by Skype, and making those clients highly resistant to inspection or modification, prevents malicious clients from entering the network
137
P2P: scalability – 1/2 The performances of a P2P system (e.g., the time
to find a file) become worse as the number of nodes increases (linearly) The “work” for a node increases linearly with respect to
the number of nodes The protocols used by Napster and Gnutella are
not scalable A second generation of P2P protocols has been
realized which support DHT (Distributed Hash Table) in order to improve their scalability Examples are Tapestry, Chord, Can, Viceroy, Koorde,
Kademlia, Kelips …
138
P2P: scalability – 2/2 The degree of scalability of a given protocol
depends on the efficiency of the adopted routing algorithm (lookup)
Two main objectives: To minimize the number of message to complete the
lookup To minimize, for each node, information about other
nodes in the network
DHT P2P differ into the routing strategy they adopt
Summary The basic architectural styles are few and their
properties should be studied and exploited Their descriptions and properties are better
understood using a modeling notation The architectural models and descriptions can be
exploited by a technology like UML via automatic transformations: see the Model Driven Architecture
139
Self test questions
140
Describe an example application architecture for each of the following styles: pipe-and-filter, repository, client-server, peer-to-peer
Discuss the difference between the active and passive repository styles
What are the advantages of P2P over client-server style?
References
Taylor et al., Software Architecture, Wiley 2009 Qian et al., Software Architecture and Design Illuminated, Jones
and Bartlett, 2009 Garland, Large-Scale Software Architecture: A Practical Guide
using UML, Addison-Wesley, 2005 Fielding & Taylor, Principled Design of the Modern Web
Architecture, ACM Trans. on Internet Technology, 2:2, 2002 Rao, Using UML service components to represent the SOA
architecture pattern, 2007 www.ibm.com/developerworks/architecture/library/ar-logsoa/
Useful sites www.softwarearchitectureportal.org! www.dossier-andreas.net/software_architecture/!
www.bredemeyer.com/links.htm! www.opengroup.org/architecture/! www.iasahome.org! alistair.cockburn.us!
Questions?
"We are searching for some kind of harmony between two intangibles: a form which we have not yet designed and a context which we cannot properly describe.”
Christopher Alexander