Chapters 12/31 Chapters 12/31

Chapters 12/31
Distributed Systems
Architectures & Service-Oriented
Software Engineering
©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 1

Distributed Systems Architectures
Architectural design for software that executes

on more than one processor

Service Oriented Software Eng
Service-Oriented
A way of developing distributed systems where

the components are stand-alone services.
“Currently a hot topic…as important a
development as object-oriented software
engineering.”
(For Chap 31, skip sections: 31.2 and 31.3.1)

Objectives
z To explain the advantages and disadvantages of
distributed systems architectures.
z To describe different approaches to the development of
client-server
li systems.
z To explain the differences between client-server and
distributed object architectures.
architectures
z To describe object request brokers and the principles
underlying the CORBA standards.
z To introduce service-oriented SE, an increasingly
important approach in business application development.

Topics covered
z Multiprocessing systems
z Distributed systems architectures
Client-server architectures
Distributed object architectures
z CORBA (Common Object Request Broker
Architecture)
z Service-oriented SE

Topics covered
z Multiprocessing systems
z Distributed systems architectures
Client-server architectures
z CORBA (Common Object Request Broker
Architecture)
z Service-oriented SE

Multiprocessor architectures
z System composed of multiple processes which
may or may not execute on different processors.
z Distribution of process to processor may be pre pre-
determined (e.g., by type of process) or may be
under the control of a dispatcher.
p

A multiprocessor traffic control
system
Sensor Traffic flow Traffic light control

processor processor processor
Sensor Light
Display control
control process
process process
Traffic lights
Traffic flow sensors
and cameras Operator consoles
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 8

Types of multiprocessing systems
z Personal systems that are not distributed and that
are designed to run on a personal computer or
workstation. ((e.g.,
g , word processors)
p )
z Embedded systems that run on a single

processor or on an integrated group of processors.
(e.g., control systems, real-time systems)
z Distributed systems
y where the system
y software
runs on a loosely integrated group of processors
linked by a network. (e.g., ATM systems)

Distributed systems
z Virtually all large, computer
computer-based
based systems
are now distributed systems.
z Processing is distributed over several computers
rather than confined to a single machine.
z Distributed software engineering
g g is now veryy
important.

Distributed system
characteristics / advantages
z Resource sharing (hardware and software)
z Openness (standard protocols allow equipment and software
from different vendors to be combined)
z Concurrency (parallel processing)
z Scalability (up to capacity of network)
z Fault tolerance (potential)
z Transparency (resources can be accessed without knowledge
of their physical or network location – item deleted after 6th
Ed.)

Distributed system disadvantages
z Complexity (number of factors affecting emergent properties)
z Security (multiple access points, network eavesdropping, etc.)
z Manageability (heterogeneity)
(h t it )
z Unpredictable responsiveness

Design issue Description
Resource The resources in a d istributed system are spread across different
id tifi ti
identification computers
t and d a naming
i scheme
h h to
has t be
b ddevised
i d so that
th t users can
discover and re fer to the resources that they need. An exa mple of
such a naming scheme is the URL (Uniform Resource Locator) that
is used to identify WWW pages. If a meaningful and universally
understood identification scheme is not used then many of these
resources will be inaccessible to system users.
Communications The universal availability of the Internet and the efficient
implementation of Internet TCP/IP communication protocols means
that, for most distributed systems, these are the most effective way
for the computers to communicate. However, where there are
specific requirements for performance, reliability etc. alternative
approaches to communications may be used.
Quality of service The quality of service offered by a system reflects its performance,
availability and reliability.
reliability It is affected by a number of factors such
as the allocation of processes to processes in the system, the
distribution of resources across the system, the network and the
system hardware and th e adaptability of the system.
Software
f The software architecture describes how the application
pp
architectures functionality is distributed over a number of logical components and
how these components are distributed across processors. Choosing
the right architecture for an application is essential to achieve the
desired quality of service.
Issues in distributed system design

Distributed systems architectures
z Client server architectures – distributed
Client-server di t ib t d
services are called on by clients. Servers that provide
services are treated differently from clients that use
services.
z Distributed object architectures – removes
distinction between clients and servers. Any object in the
system may provide and use services from other objects.

Middleware
z Software that manages and enables commun-
commun
ication between the diverse components of a
distributed system.
y
z Usually off-the-shelf rather than specially
written.
z Distributed system frameworks, e.g. CORBA
and DCOM,, is an important
p class of middle-
ware described later.

Client server architectures
Client-server
z The application is modelled as a set of services
that are provided by servers and a set of clients
that use the services.
z Clients must know of servers but servers need
not know of clients. (e.g., “installing” a network printer)
z Clients and servers are logical processes as
opposed to physical machines.
z The mapping of processors to processes is not
necessarily 1:1.

P
Processes i a client-server
in li t system
t
c2 c3 c4 c12
c11
Server process
c1 s1 s4
c10
c5
Client process
s2 s3 c9
c6 c8
c7

C
Computers
t i a client-server
in li t network
t k
c1 c2 c3, c4
CC1 CC2 CC3
Network s3, s4 Server

s1, s2
computer
SC2 SC1
Client
computer
c5, c6, c7 c8, c9 c10, c11, c12
CC4 CC5 CC6

Application layers model
z Presentation layer – concernedd with
ith
presenting the results of a computation to system
implemented
users and with collecting user inputs. on client only
z Application processing layer – concerned
with implementing the logic (functionality) of the
application. implemented on client or server
z Data management layer – concerned with
all system database operations. implemented on
server only

Application layers
Presentation layer
Application processing
layer
Data management
layer

Distributing layers to processors
z Two-tier C/S architecture – the three layers are
distributed between a server processor and a set of
clients.
z Three-tier C/S architecture – the layers are
distributed among two server processes / processors
and a set of clients.
clients
z Multi-tier C/S architectures – the layers are
distributed amongg multiple
p server pprocesses /
processors (each associated with a separate database,
for example) and a set of clients.

Two-tier architectures: thin
and fat clients
z Thin client model – the
Thin-client th application l i and
li i logic d
data management are implemented on the server;
clients only handle the user interface.
z Fat-client model – the server is only
responsible for data management; clients handle the
application logic and the user interface.

Thin and fat clients
Presentation
Server
Thin-client Data management
model Client
Application
processing
Presentation
Application processing Server
Fat-client
model Client Data
management

Thin client model
Thin-client
z Often used when centralized legacy systems
evolve to a C/S architecture; the user interface
is migrated to workstations or terminals and the
legacy system acts as a server
server.
z Places a heavy processing load on both the
server and the network; this is wasteful when
clients are powerful workstations.

Fat client model
Fat-client
z More processing is delegated to the client as
the application logic is executed locally (i.e., on
the client).
z But system management is more complex,
especially when application function changes
and new logic must be installed on each client.
client

A client
client-server
server ATM system
fat- or thin-client
model?
ATM
ATM Account server
Tele- Customer
processing account
ATM monitor database
ATM
transaction manager

Three tier architectures
Three-tier
z Each application architecture layer may execute
on a separate processor.
z Allows for better performance and scalability
than a thin-client approach and is simpler to
manage than a fat-client approach. (Why?)

A 33-tier
tier C/S architecture
Presentation
Server Server
Client Application Data
processing management

An internet banking system
Client HTTP interaction
Web server Database server

SQL query
Client Account service Customer
SQL account
provision
database
Client
Application Data
processing management
Client
Presentation

Use of C/S architectures
Architecture Applications
T
Two-tier
ti C/S L
Legacy system
t applications
li ti where
h separating
ti application
li ti
architecture with processing and data management is impractical
thin clients Computationally-intensive applications such as compilers with
little or no data management
Data-intensive applications (browsing and querying) with little
or no application processing.
Two-tier C/S Applications where application processing is provided by
architecture with COTS ((e.g. g Microsoft Excel)) on the client
fat clients Applications where computationally-intensive processing of
data (e.g. data visualisation) is required.
Applications with relatively stable end-user functionality used
in an environment with well-established system management
Three-tier or Large scale applications with hundreds or thousand s of clients
multi-tier C/S Applications where both the data and the application are
architecture volatile.
A li ti
Applications where
h d t from
data f multiple
lti l sources are integrated
i t t d

Review of C/S system models/types
z Two logical process types
servers (providing services)
clients (using services)
z Three application layers
presentation (always associated with clients)
processing logic (thin model: associated with server; fat
model: associated with clients)
data management (always associated with servers)
z Three layer-to-processor mappings
2-tier (1 server + a set of clients)
3-tier (2 servers + a set of clients)
multi-tier (n servers + a set of clients)

z Eliminates the distinction between clients and
servers.
z System components are objects that provide
services to, and receive services from, other
objects.
z Object communication is through middleware
called an object request broker (effectively a
software bus)

Object name
o1 o2 o3 o4
S (o1) S (o2) S (o3) S (o4)
Software bus (ORB)
o5 o6
S (o5) S (o6)
Services

Advantages of distributed
object architectures
z Allows system designer to delay decisions on
where and how services should be provided.
(Service-providing objects may execute on any network node.)
z Very open architecture – allows new resources
to be added as required.
z Flexible and scaleable.
z System is dynamically reconfigurable – objects
can migrate across the network as required. (Thus
improving performance.)

Uses of distributed object
architectures
1 As a logical model for structuring and
1.
organizing a system solely in terms of
services provided by a number of distributed
objects. (E.g., a data mining system.)
2. As a flexible means of implementing C/S
systems. Both clients and servers are realised
as distributed objects communicating through
a software bus.
bus

A data mining system
Database 1 Report gen.
Integrator 1
Database 2
Visualiser
Integrator 2
Database 3
Display

Disadvantages of distributed
object architectures
z Complex to design due to model generality
and flexibility in service provision.
z C/S systems seem to be a more natural model
for most systems. (They reflect many human
service transactions.)

CORBA (Common Object Request
Broker Architecture) – est.
est 1991
z International standards for an Object Request Broker
(ORB) – middleware to manage communications between
distributed objects. (Version 3.1, 2008)
z Several implementations of CORBA are available (Unix
and MS OS’s). www.corba.org
z Defined by the Object Management Group (> 500
companies, including Sun, HP, IBM). (OMG → UML)
z DCOM (Distributed Component Object Model) is an
alternative standard developed and implemented by
Microsoft – now deprecated in favor of Microsoft .NET

Components of the OMG vision
of a distributed application
z Application objects designed and implemen-
implemen
ted for this application.
z Domain-specific
Domain specific objects defined by the OMG.
(e.g., finance/insurance, healthcare)
z Fundamental CORBA distributed computing

services
i suchh as di
directories
t i andd security
it
management.
z Horizontal facilities (such as user interface
facilities) used in many different applications.
(cross domain)

CORBA application structure
Application Domain Horizontal
objects facilities CORBA facilities
Object request broker
CORBA services

The OMG Vision
Application
specific
Horizontal
facilities
Domain
specific
facilities CORBA
services
i
Major elements of the CORBA
standards
• An application object model where objects
encapsulate state and have a well-defined, language-
neutral interface defined in an IDL (interface
d fi i i language).
definition l )
• An object request broker (ORB) that locates objects
providing services, sends service requests, and
returns results to requesters.
• A set of general object services of use to many
di ib d applications.
distributed li i (Horizontal facilities)
• A set of common components built on top of these
services. (Task forces are currently defining these.)
(domain specific facilities)
CORBA objects
z Objects that provide services have IDL
skeletons that link their interface to an
implementation.
p
z Calling objects have IDL stubs for every
object
j beingg called.
z IDL stubs and skeletons are “visible” to ORB.
z Objects
j do not need to know the location or
implementation details of other objects.

Object request broker (ORB)
z The ORB handles object communications
communications. It
knows of all objects in the system and their
interfaces.
z The calling object binds an IDL stub that
defines the interface of the called object.
j
z Calling this stub results in calls to the ORB
which then calls the required object through a
published IDL skeleton that links the interface
to the service implementation.

ORB based object communications
ORB-based
o1 o2
S (o1) S (o2)
Calling Object
object providing
IDL IDL service
stub skeleton
(For 02)
Object Request Broker

Inter ORB communications
Inter-ORB
z ORBs handle communications between objects
executing on the same machine.
z Inter ORB communications are used for
Inter-ORB
distributed (remote) object calls.
z CORBA supports
pp ORB-to-ORB communication
by providing all ORBs access to all IDL interface
definitions and by implementing the OMG’s
standard Generic Inter-ORB Protocol (GIOP)
(GIOP).

Inter ORB communications
Inter-ORB
o1 o2 o3 o4
S (o1) S (o2) S (o3) S (o4)
IDL IDL IDL IDL
Object Request Broker Object Request Broker
Network
GIOP

Examples of general CORBA
services
z Naming and trading services – these allow
objects to discover and refer to other objects on the
network.
z Notification services – these allow objects to
notify other objects that an event has occurred.
(selective broadcasting)
z Transaction services – these support atomic
transactions and rollback on failure. (recovery
( y
functions)

The future of CORBA support
for Internet computing
z Proponents of CORBA envisioned it as becoming
the dominant model for code and service-reuse
over the Internet.
z However difficulties encountered with firewalls,
insecure machines, etc., have resulted in an
increased use of normal HTTP requests in
combination with web browsers, as well as
i
interest in
i other
h models
d l off inter-organizationall
computing…

Inter organizational computing
Inter-organizational
z For security and inter-operability reasons,
reasons most
distributed computing has been implemented at
the enterprise level.
z Local standards, management and operational
processes apply.
z Newer models of distributed computing have
been designed to support inter-organisational
computing
i where
h diff
different nodes
d are located
l d in
i
different organizations.

Peer to peer architectures
Peer-to-peer
z Peer to peer (p2p) systems are decentralised
systems where computations may be carried out
by any node in the network.
z The overall system is designed to take
advantage of the computational power and
storage of a large number of networked
computers.
z Most p2p systems have
h been
b personall systems
but there is increasing business use of this
technology
technology.

S i
Service-oriented
i t d architectures
hit t (Ch.
(Ch 31)
z A means of developing distributed systems
where the components are stand-alone (usually
web-based) services
z Standard, XML-based protocols have been
developed to support service communication
and information exchange (“perhaps
( perhaps the key
reason for success”)
z Services are platform and language independent.
z Systems can be constructed using services from
different providers (using a workflow language)
with seamless interaction
interaction.
Web services
Service
registry
Find Publish
Service Service Service

requestor provider
id
Bind

Web service standards
XML technologies (XML, XSD, XSLT, ....)
Support (WS-Security, WS-Addressing, ...)
Process (WS-BPEL)
Service definition (UDDI, WSDL)
Messaging (SOAP)
Transport (HTTP, HTTPS, SMTP, ...)

Principal XML-based
XML based standards
z Messaging: SOAP (Simple Object Access Protocol):
message exchange standard that supports service
communication
z Service Definition:
WSDL (Web Service Definition Language): defines a
service interface and its bindings
UDDI (Universal Description, Discovery and
Integration): defines the components of a service that
may be used to discover its existence
z Process: WS-BPEL (Web Service Business Process
Execution Language): standard for workflow languages
used to define service composition

Web services
(UDDI)
Service
registry
Find Publish

requestor provider
id
Bind (SOAP) (WSDL)

Principal XML-based
XML based standards
communication

Web services
(UDDI)
Service
registry
Find Publish

requestor provider
id
Bind (SOAP) (WSDL)

Principal XML-based
XML based standards
communication

Web services
(UDDI)
Service
registry
Find Publish

requestor provider
id
Bind (SOAP) (WSDL)

Principal XML-based
XML based standards
communication

Examples of “Supporting standards”
z WS-Reliable
WS Reliable Messaging: ensures messages
will be delivered once and once only
z WS-Security:
WS Security: specify security policies and
standards for use of digital signatures
z WS-Addressing:
WS Addressing: specifies representation of
addresses in SOAP messages
z WS-Transactions: specifies
p how transactions
should be coordinated across services

S i
Services as reusable
bl components
t
z A service can be defined as:
A loosely-coupled,
l l l d reusable
bl software
ft componentt
that encapsulates discrete functionality which
may be distributed and programmatically
accessed. A web service is a service that is
accessed using standard Internet (HTTP
(HTTP,
TCP/IP) and XML-based protocols.

S i
Services as reusable
bl components
t ((cont’d)
t’d)
z A critical distinction between a service and a
component as defined in CBSE is that
services are independent.
independent
Services do not have a ‘requires’ interface
Services rely on message-based
message based
communication using XML (versus
synchronous
sy c o ous method
et od calls)
ca s)
(CBSE covered in Chap. 19)

Message-based communication vs.
i t
interaction
ti via
i method
th d calls
ll
restaurant order via synchronous method calls

Message-based communication vs.
i t
interaction
ti via
i method
th d calls
ll (cont’d)
( t’d)
restaurant order via an XML message
<starter>
<dish name = “soup” type = “tomato” />
<dish name = “soup” type = “fish” />
<dish
di h name = “pigeon
“ i salad”
l d” />
/
</starter>
<main course>
<dish name = “steak”
steak type = “sirloin”
sirloin cooking = “medium”
medium />
<dish name = “steak” type = “fillet” cooking = “rare” />
<dish name = “sea bass”>
</main course>
<accompaniment>
<dish name = “french fries” portions = “2” />
<dish name = “salad” portions = “1” />
</accompaniment>

Software development with services
z Existing services are composed and configured to
create new composite services and applications.
z The basis for service composition is often a
workflow.
Workflows are logical
g sequences
q of activities that,,
together, model a coherent business process.
For example, consider a workflow providing a travel
reservation
ti services
i which
hi h allows
ll flights,
fli ht car hire
hi andd
hotel bookings to be coordinated…

Service composition
z Suppose an airline wishes to compose its own
booking services with services offered by a hotel
bookingg agency,
g y, car hire and taxi companies,
p , and
local attraction providers.
z The sequence
q of steps
p for this “vacation ppackage”
g
application could be modeled (in simplified form)
as the following workflow:

Vacation package workflow
Note that this simplified model does NOT reflect the

possibility of service failure, exceptional user
requests, etc.

Construction by composition
The process of designing new services by composing

existing services is, essentially, a process of software
design with reuse.

External service testing issues
z Services are “black-boxes,”
black boxes, so code
code-based
based (i.e.,
(i e , “white-
white
box”) testing techniques cannot be used at the service
level.
z S i
Services may be
b modified
difi d by
b the
th service
i provider.
id
z Dynamic binding means that the service used in an
application
pp mayy vary.
y
z Non-functional behavior is unpredictable as it depends
on other (concurrent) uses of the service.
z If services have to be paid for as used,
used testing may be
expensive.
z It may be difficult to test compensating actions which
rely on the failure of services.
Key points
z Almost all new large systems are distributed
systems.
z Distributed systems support resource sharing,
openness, concurrency, scalability, fault tolerance,
and transparency.
z Client-server architectures involve services being
delivered by servers to programs operating on
clients.
clients
z User interface software always runs on the client
and data management on the server.
server
Key points (cont’d)
z In a distributed object architecture
architecture, there is no
distinction between clients and servers.
z Distributed object systems require middle-ware to
handle object communications.
z The CORBA standards are a set of middle
middle-ware
ware
standards that support distributed object
architectures.
z Peer to peer architectures are decentralised
architectures where there is no distinction between
clients and servers.
Key points (cont’d)
z Service oriented software engineering is based on
Service-oriented
the notion that programs can be constructed by
composing independent services which encapsulate
reusable
bl ffunctionality.
i li
z Service interfaces are defined in WSDL. A WSDL
specification includes a definition of the interface
types and operations, the binding protocol used by
the service, and the service location.
z Service-level code-based testing cannot be used in
service-oriented systems that rely on externally
provided services
services.
Chapters 12/31
Distributed Systems
Architectures & Service-Oriented
Software Engineering

Chapters 12/31 Chapters 12/31

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chapters 12/31 Chapters 12/31

Uploaded by

Copyright:

Available Formats

Chapters 12/31

©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 1

Architectural design for software that executes

©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 2

A way of developing distributed systems where

(For Chap 31, skip sections: 31.2 and 31.3.1)

©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 3

©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 4

©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 5

©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 6

©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 7

Sensor Traffic flow Traffic light control

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 8

z Embedded systems that run on a single

©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 9

©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 10

©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 11

©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 12

Issues in distributed system design

©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 14

©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 15

©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 16

©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 17

Network s3, s4 Server

©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 18

©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 19

©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 20

©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 21

©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 22

©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 23

©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 24

©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 25

ATM Account server

©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 26

©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 27

©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 28

Client HTTP interaction

Web server Database server

©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 29

©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 30

©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 31

©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 32

S (o1) S (o2) S (o3) S (o4)

Software bus (ORB)

©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 33

©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 34

©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 35

©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 36

©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 37

©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 38

z Fundamental CORBA distributed computing

©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 39

Object request broker

©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 40

©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 43

©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 44

Object Request Broker

©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 45

©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 46

S (o1) S (o2) S (o3) S (o4)

IDL IDL IDL IDL

Object Request Broker Object Request Broker

©Ian Sommerville 2000 Software Engineering. Chapters 12/31 Slide 47