The document discusses architectural styles and decomposition techniques. It describes layers as hierarchical sets of subsystems that provide related services by utilizing underlying layers. Tiers partition a system into peer subsystems responsible for classes of services. Common architectural styles include pipes and filters, repository, client/server, model-view-controller, service-oriented, and peer-to-peer. Layers and tiers are often combined for complete decomposition, with subsystems divided into tiers and each tier organized into layers. The pipe and filter style focuses on dynamic interaction by processing data streams through filters connected by pipes.

1. Architectural styles
Paolo Ciancarini

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
2

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

5. Layers of virtual machines
5

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

12. Creating layers: façade
12

13. 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
14

15. 15

16. Typical tiered architecture
16

17. 4 tiers architecture
17

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

20. Architectural variants

21. Pipes and Filters style

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
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

30. Pipe and Filter Sequence Diagram

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

34. “Architectural” package diagram
UML
<<metaclass>> <<metaclass>>
Component Connector
Pipes&filters
<<stereotype>> <<stereotype>>
Filter Pipe
34

35. Component diagram
<<pipe>> <<pipe>> <<pipe>> <<pipe>> <<pipe>> <<pipe>> <<pipe>> <<pipe>>
<<filter>> <<filter>> <<filter>> <<filter>>
<<component>> <<component>> <<component>> <<component>>
pic eqn tbl troff
35

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.

37. Repository-based style

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

39. Repository Architecture
Agent 2
Agent 1
Repository
Agent 3
Agent 4
Agent n
39

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

44. publish/subscribe
44

45. Observer pattern
45

46. Publish subscribe variants
46

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

49. Client-Server style

50. Client server
remote remote remote
50

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

55. Client-server style
 2 tiers Client/Server architectures
Fat server Fat client 55

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

64. Three-tier architectures – 3/6
64

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

69. Example N-tiers
69

70. Model/View/Controller style

71. 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
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

74. Basic interaction for MVC
74

75. Initialization for MVC
75

76. MVC interactions
76

77. 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
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 may seem similar to the model-
view-controller (MVC) concept; 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

82. 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
82

83. Service-Oriented style
(SOA)

84. A world of services
84

85. The service-oriented architecture model
85

86. SOA, web service style (use cases)
86

87. 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 87

88. 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
88

89. 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
89

90. Service computing: layered style
90

91. SOA layers, IBM style
91

92. 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
92

93. 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
93

94. 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
94

95. Interaction: State diagram
95

96. 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
96

97. SOA model
 1 Service Consumer
 2 Service Provider
 3 Service Registry
 4 Service Contract
 5 Service Proxy
 6 Service Lease
97

98. SOA in UML
98

99. SOA elements
99

100. 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
100

101. 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.
101

102. Service composition
Jeff Hanson, Coarse-grained Interfaces Enable Service Composition in SOA, JavaOne, August 29, 2003
102

103. 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
103

104. 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)
104

105. 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
105

106. 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
106

107. 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
107

108. WSDL
108

109. 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).
109

110. 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
110

111. WS and XML
 All Web Services documents are written in XML
 XML Schema are used to define the elements used
in Web Services communication
111

112. 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
112

113. 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
113

114. 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
114

115. 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
115

116. 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
116

117. 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
117

118. Cloud computing
 Software as a service, like Web services
 Platform as a service, like mashups
 Infrastructure as a service (or hardware as a
service)
118

119. Peer-to-peer style
P2P

120. 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
120

121. 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
121

122. Peer-to-peer architectures
 Functional characteristics of typical P2P systems
 File sharing system
 File storage system
 Distributed file system
 Redundant storage
 Distributed computation
 Nonfunctional requirements
 Availability
 Reliability
 Performance
 Scalability
 Anonymity
122

123. 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
123

124. The phases of a P2P application
A P2P application is organized in three phases:
 Boot, during which a peer connects to the networks and
actually performs the connections (P2P boot is rare)
 Lookup, during which a peer looks for a provider for a
given service or information (generally providers are
SuperPeers)
 Resource sharing, during which requested resources
are delivered, usually in several segments
124

125. 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.
125

126. 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
126

127. Napster

128. Gnutella (original)

129. Gnutella
129

130. Gnutella: search
130

131. Gnutella: reply
131

132. Skype

133. 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

134. 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 …
134

135. 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
135

136. Summary
 The basic architectural styles are few and their
properties should be studied and become known
 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
136

137. 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?
137

138. 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/

139. 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!

140. Questions?