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)
3
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
4
6. Layers: component diagram
Connectors for layered systems
are often procedure calls
Each level implements a
different VM with a specific input
language
6
7. 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)
C1 C1 C1
attr attr attr VM1
op op op
C1 C1
attr attr VM2
op op
C1 C1
attr attr VM3
op op
C1 C1
attr attr VM4
op op
8
9. Closed layers: ISO/OSI stack
The ISO/OSI reference Application
model defines 7 network
layers, characterized by an Presentation
increasing level of
Level of abstraction
Session
abstraction
Eg. The Internet Protocol Transport
(IP) defines a VM at the
network level able to identify Network
net hosts and transmit
single packets from host to DataLink
host
Physical 9
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 C1 C1
attr attr attr
op op op
C1 C1
attr attr
op op
C1 C1
attr attr
op op
C1 C1
attr attr
op op
10
11. Open layers: OSF/Motif
Application
Motif
Xt
Xlib
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
14. Tiers
Another approach to managing complexity consists
of partitioning a system into sub-systems (peers),
which are responsible for a class of services
14
18. 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
19
22. 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 This architecture style focuses
on the dynamic (interaction)
rather than the structural
pipe
23. Batch sequential data flow
Rejected
transaction
-123 U
Validated Sorted
Transaction File
transaction transaction
222 U
222 U 111 I
111 I
Validate 111 I sort 222 U
333 D
333 D 333 D
-123 U
100 ----
Update
111 ----
200 ----
222 ----
Generate Report 444 ----
Reports 100 ---
Updated 200 ---
Master file 222 ---
333 ---
444 ---
Master file
23
24. 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”
Note the pipe
cat swarch.txt | grep studio | wc symbol, l
25. 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?
26. 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 Prepare for
Process Checks
time cards Check processing
Problems that require batch file processing seem to fit this: payroll and compilers
27. 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
Splitting the good time
cards from the bad ones
Validate for
payroll processing
Manually Reprocess Automatically
Card and Cut Check Process Checks
Do the data streams
Payroll report need to be synchronized
here for report?
28. Pipes and filters
Pipe: communication channel
Filter: computing component
Filter 1 may only send data to Filter 2 Filter 1 Pipe Filter 2
Filter 2 may only receive data from Filter 1 (Source) (Sink)
Filter 1 may not receive data
Filter 2 may not send data
Pipe is the data transport mechanism
* input output 1
Filter Pipe
* output input 1
+Read()
+Write()
29. Pipe and Filter Class Diagram
Pipe
Filter
+Read()
+Write()
Data Source Data Sink
+read() +write()
30. Pipe and Filter Sequence Diagram
data source: filter1: pipe: filter2: data sink:
Data Source Filter pipe Filter Data Sink
read
Filter1
W
Filter2
R
write
Data Source Filter1 Filter2 Data Sink
pipe
31. 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
32. 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
33. Pipe and Filter Sequence Diagram
active passive active
Pull only Pull /push Pull / push Pull /push Push only
data source Filter 1 Pipe Filter 2 data sink
R ead R ead
( blocking )
Wr ite
R ead
R ead
Wr ite
Wr ite
R ead
36. 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.
38. 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)
Physician Lab testing
diagnosis
Patient
database Accounting
Pharmacy & & administration
drug processing
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
40. 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
Repository
Subsystem
createData()
setData()
getData()
searchData()
41. Example: a compiler architecture based on a repository
Compiler
SemanticAnalyzer
SyntacticAnalyzer
Optimizer
LexicalAnalyzer CodeGenerator
Repository
ParseTree SymbolTable
SourceLevelDebugger SyntacticEditor
41
42. 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
43. 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
47. 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
48
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
51
52. Client-server paradigm
The first generation of distributed systems was
based on the client server style
2nd Generation
Distributed
Objects
1st Generation
Client/Server
distribution
Mainframe
Degree of
Monolithic
Complexity & adaptability 52
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
Server
Client * *
requester! provider!
service1()
service2()
serviceN()
53
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
Application
Data
Presentation
processing management
54
56. 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
Web browser
2. A series of Web server
1.tubes
DNS server
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
56
57. A Conversation With a Web Server
GET /index.html HTTP/1.0
User-Agent: Mozilla/4.73 [en] (X11;HTTP method & URIi686)
U; Linux 2.0.35
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 Cookie data: up to
Content-Length: 16018 4KiB
Set-Cookie: B=2vsconq5p0h2n
Content-Type: text/html
MIME content type
<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">
57
58. 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
59
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
60
61. 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
Client request service Server
do_task run_service
Dispatcher
Location_map
request establish
locate_Server connection
connection
61
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
62
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
63
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
65
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
66
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
67
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
68
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
initiator
Controller
* 1 repository
Model
1 notifier
subscriber
View
*
72
73. 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
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
78
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
79
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
2.User types new filename
:Controller 3. Request name change in model
1. Views subscribe to event
:Model
5. Updated views
:InfoView 4. Notify subscribers
:FolderView
80
81. 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
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
83
89. Service-oriented architectures
SOAs represent an evolution of client-server
architectures
3rd generation of distributed software systems
Distribution degree and mobility
1st generation 2nd generation 3rd generation
SOAs
Distributed
objects
C3
C1
C2
C4 C5
client-server
3 levels
Distributed
components
2 levels
Complexity 89
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
90
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
91
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
94
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
95
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
96
98. SOA building blocks – 2/2
Service registration (provider) and lookup (requestor) in the
registry
Service access
SERVICE
Service lookup
REGISTRY
Service registration
SERVICE
SERVICE
REQUESTOR
PROVIDER
Service access
PDA
Laptop
Desktop
Computer
98
99. SOA model
1 Service Consumer
2 Service Provider
3 Service Registry
4 Service Contract
5 Service Proxy
6 Service Lease
99
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
102
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.
103
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
105
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)
106
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
107
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
108
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
110
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).
112
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
113
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
114
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
115
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
116
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
117
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
118
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
119
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
120
121. 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
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 requester
*
service1()
service2() *
…
serviceN() provider
123
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
124
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
125
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
126
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
127
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.
128
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
129
136. 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 …
137
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
138
139. 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
140. Self test questions
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?
140
141. 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/
143. 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
