Distributed Systems Architectures

1
Distributed Systems Architectures
2
Objectives

• To explain the advantages and disadvantages of
  different distributed systems architectures
• To discuss client-server and distributed object
  architectures
• To describe object request brokers and the
  principles underlying the CORBA standards
• To introduce peer-to-peer and service-oriented
  architectures as new models of distributed
  computing.

3
Distributed systems

• Virtually all large computer-based systems are
  now distributed systems.
• A distributed system is a system where
  Information processing is distributed over
  several computers rather than confined to a
  single machine.
• Distributed software engineering is therefore
  very important for enterprise computing systems.

4
Distributed system characteristics

• Resource sharing
• sharing of hardware and software resources.
• Openness
• use of equipment and software from different
  vendors.
• Concurrency
• concurrent processing to enhance performance.
• Scalability
• increased throughput by adding new resources.
• Fault tolerance
• the ability to continue in operation after a
  fault has occurred.

5
Distributed system disadvantages

• Complexity
• distributed systems are more complex than
  centralized systems.
• Security
• More susceptible to external attack.
• Manageability
• More effort required for system management.
• Unpredictability
• Unpredictable responses depending on the system
  organisation and network load.
• Design challenge
• achieve advantages while minimizing problems

6
Issues in distributed system design
7
Distributed systems architectures

• Client-server architectures
• distributed services which are called on by
  clients.
• servers that provide services are treated
  differently from clients that use services.
• Distributed object architectures
• no distinction between clients and servers.
• any object on the system may provide and use
  services from other objects.
• Architectures for inter-organization
• peer-to-peer architectures
• service-oriented architectures

8
Middleware

• The components in a distributed system may be
  heterogeneous
• programming language, execution platform
• Software that manages and supports the different
  components of a distributed system.
• it sits in the middle of the system.
• Middleware is usually off-the-shelf rather than
  specially written software. For example,
• transaction processing monitors
• data converters
• communication controllers.

9
Middleware Concept
Application
Application
Middleware
Middleware
Operating System
Operating System

• Software that functions as a conversion or
  translation layer.
• It is also a consolidator and integrator.
• Custom-programmed middleware solutions have been
  developed for decades to enable one application
  to communicate with another that either runs on a
  different platform or comes from a different
  vendor or both.
• Today, there is a diverse group of products that
  offer packaged middleware solutions.

10
Middleware Services

• provide a more functional set of Application
  Programming Interfaces (API) than the operating
  system and network services to allow an
  application to
• locate transparently across the network,
  providing interaction with another application or
  service
• be independent from network services
• be reliable and available
• scale up in capacity without losing function

11
The Middleware Layer
12
Multiprocessor architectures

• Simplest distributed system model.
• System composed of multiple processes which may
  (but need not) execute on different processors.
• Architectural model of many large real-time
  systems.
• Distribution of process to processor may be
  pre-ordered or may be under the control of a
  dispatcher.
• Software systems composed of multiple processes
  are not necessarily distributed systems.

13
A multiprocessor traffic control system
14
Client-server architectures

• An application is modelled as
• a set of services that are provided by servers,
  and
• a set of clients that use these services.
• Clients know of servers but servers need not know
  of clients.
• Clients and servers are logical processes
• the mapping between processes to processors is
  not necessarily 1 1
• several server processes can run on a single
  processor

15
A client-server system
16
Computers in a C/S network
17
Layered application architecture

• The design of a client-server system should
  reflect the logical structure of the application
• a common solution is to apply a layered style
• Presentation layer
• concerned with presenting the results of a
  computation to system users and with collecting
  user inputs.
• Application processing layer
• concerned with providing application specific
  functionality
• e.g., in a banking system, banking functions such
  as open account, close account, etc.
• Data/resource management layer
• concerned with managing the system databases.

18
Application layers
19
Layers and tiers

• When implementing real systems, layers can be
  combined and distributed in different ways
• In this case, we refer to them as tiers
• One-tier architectures
• Monolithic architecture mainframedumb terminals
• Two-tier architectures
• thin-client, fat-client
• Three-tier architectures
• N-tier architectures

20
One-tier architecture
Information system
21
Two-tier architures

• Thin-client model
• in this model, all of the application processing
  and data management is carried out on the server
• the client is simply responsible for running the
  presentation software
• sometimes, the client and presentation layers are
  merged into one, e.g. applets and swing clients
• however, it is not always correct to refer to
  presentation layer as the client, e.g. web
  clients
• Fat-client model
• in this model, the server is only responsible for
  data management
• the software on the client implements the
  application logic and the interactions with the
  system user.

22
Thin and fat clients
23
Thin client model

• It is the simplest approach to use when legacy
  systems are migrated to client server
  architectures.
• the legacy system acts as a server in its own
  right with a graphical interface implemented on a
  client.
• This model may also be implemented when clients
  are simple devices rather than PCs
• A major disadvantage is that it places a heavy
  processing load on both the server and the
  network.
• The processing power of the client computer is
  largely unused

24
Thin-client 2-tier architecture

25
Fat client model

• In this model, both the application logic and
  presentation are running on the client.
• Most suitable for new C/S systems where the
  capabilities of the client system are known in
  advance.
• System management is more complex than a thin
  client model
• new versions of the application have to be
  installed on all clients.
• The advent of mobile code (e.g. applets that can
  be downloaded from the server) can simplify such
  management activities

26
Fat-client 2-tier architecture
27
A client-server ATM system
28
Three-tier architectures

• In a three-tier architecture, each of the
  application architecture layers may execute on a
  separate processor.
• allows for better performance than a thin-client
  approach and
• is simpler to manage than a fat-client approach.
• A more scalable architecture
• as demands increase, extra servers can be added.

29
A 3-tier C/S architecture
30
3-tier client-server architecture
31
An internet banking system

32
Use of client-server architectures

• Two-tier C/S architecture with thin clients
• legacy system applications where separating
  application processing and data management is
  impractical
• 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 architecture with fat clients
• applications where application processing is
  provided by off-the-shelf software (e.g.
  Microsoft Excel) on the client
• applications where computationally-intensive
  processing of data (e.g. data visualization) is
  required
• applications with relatively stable end-user
  functionality used in an environment with
  well-established system management
• Three-tier or multi-tier C/S architecture
• large scale applications with hundreds or
  thousands of clients
• applications where both the data and the
  application are volatile
• applications where data from multiple sources are
  integrated

33
Multi-tier architectures

• In some cases, the three-tier model is extended
  to a multi-tier model
• additional servers are added to the system
• For example, an application that needs to access
  and use data from different databases
• an integrated server can be positioned between
  the application server and the database servers
• The integrated server collects the distributed
  data and present it to the application server as
  if it were from a single database

34
(No Transcript)
35
From one-tier to N-tier architectures

• With the addition of each tier
• the architecture gains flexibility, functionality
  and possibility for distribution
• the architecture introduces a performance problem
  by increasing the cost of communication
• more complexity is introduced in terms of
  management and tuning

36
Information system integration

• A common problem is to offer services based on
  the composition/integration of other services
• e.g., to evolve legacy systems

37
(No Transcript)
38
(No Transcript)
39
Distributed object architectures

• In the client-server model of a distributed
  system, clients and servers are different
• flexibility can be limited
• designers must decide where services are provided
• they must also plan for scalability
• A more general approach is to remove the
  distinction between clients and servers and to
  use a distributed object architecture

40
Distributed object architectures

• In the distributed object architecture
• the fundamental system components are objects
• each object provides an interface to a set of
  services for other objects
• objects receive services from other objects
• objects may be distributed across a number of
  computers on a network
• Object communication is through a middleware
  system called an object request broker

41
Distributed object architecture
42
Distributed object architecture

• (Server) objects register services they provide
  to the broker
• (Client) objects send requests to (server)
  objects using the broker as indirection
• Several brokers can interact via bridge
  components

43
Characteristics of distributed objectarchitecture

• Advantages of the distributed object model
• it allows the system designer to delay decisions
  on where and how services should be provided.
• it is a very open system architecture that allows
  new resources to be added to it as required.
• the system is flexible and scaleable.
• it is possible to reconfigure the system
  dynamically with objects migrating across the
  network as required.
• However, distributed object architectures are
  more complex to design than client-server systems

44
Uses of distributed object architecture

• As a logical model that allows you to structure
  and organise the system
• in this case, you think about how to provide
  application functionality solely in terms of
  services and combinations of services.
• As a flexible approach to the implementation of
  client-server systems
• the logical model of the system is a
  client-server model but both clients and servers
  are realised as distributed objects communicating
  through a common communication framework.

45
A data mining system
46
Data mining system

• The logical model of the system is not one of
  service provision where there are distinguished
  data management services.
• It allows the number of databases that are
  accessed to be increased without disrupting the
  system.
• It allows new types of relationship to be mined
  by adding new integrator objects.

47
Three Main Distributed Object Architectures

• CORBA (Common Object Request Broaker) by OMG
  (Object Management Group)
• EJB (Enterprise Java Beans)or RMI (Remote Method
  Invocation) by SUN
• DCOM (Distributed Component Object Model) by
  Microsoft

48
RMI Architecture
Application
Application
RMI Client
RMI Server
Stubs
Skeleton
Remote Reference layer
Remote Reference layer
Transport layer
Transport layer
49
EJB Architecture
50
J2EE Environment
51
EJB Type

• Entity Bean
• Session Bean
• Stateless Session Bean
• Stateful Session Bean

52
EJB Components
To implement an enterprise bean, you need to
define two interfaces and one or two classes

• Home interface
• Remote interface
• Bean class
• Primary key class (for Entity bean only)

53
CORBA Architecture
interface specification
Object Request Broker
54
CORBA Components

• IDL (Interface Definition Language)
• ORB (Object Request Broaker)
• IIOP (Internet-Inter Operability Protocol)

55
CORBA Concept

• Open standard
• Use IDL (Interface Definition Language) to write
  CORBA interface
• CORBA object can be written by ANY LANGUAGE that
  has API support CORBA
• Communicate via IIOP (Internet-Inter Operability
  Protocol) and ORB (Object Request Broaker)

56
CORBA 2.0
Object implementation
Client
Dynamic Static Invoc.
Object Adapter
Static Skeleton
Client IDL stubs
ORB Interface
Dynamic Invoc.
Object Request Broker core
57
CORBA interoperability
Client
ORB X
Object implementation
IIOP
ORB Y
58
OMG Object Management Architecture Reference Model
Spell checkers Browsers Compound
documents Reusable interfaces Print
spooling Electronic mail
Application Objects
CORBA Facilities
Object Request Broker (ORB)
Concurrency Security Time Licencing Properties Que
ries Replication
Lifecycle Naming Events Persistence Relationships
Externalization transactions
CORBA Services
59
Common Object Request Broker Architecture
(CORBA)
CORBA Services

Events

Time

Naming

Licensing

Life Cycle

Query

Persistence

Properties

Concurrency

Change Management

Externalization

Collections

Relationships

Startup

Transactions

Trading

Security

Replication
Specification adopted RFP
issued Assigned to an RFP
Object Management Group (OMG) Specification
60
DCOM What is it?

• Start with COM Component Object Model
• Language-independent object interface
• Add interprocess communication

61
DCOMDistributed COM

• Looks like COM to the client
• Built on DCE RPC
• Extends to support full COM functionality

62
DCOM Architecture
63
CORBA, EJB, DCOMComparison

• CORBA
• Language independent
• Most use in mission critical application, e.g.
  Banking
• Most popular
• EJB
• Pure Java (language dependent)
• platform independent
• Support J2EE architecture
• Become most popular
• DCOM
• Best for windows platform
• Difficult to develop mission critical application

64
Inter-organisational computing

• For security and inter-operability reasons, most
  distributed computing has been implemented at the
  enterprise level.
• Local standards, management and operational
  processes apply.
• Newer models of distributed computing have been
  designed to support inter-organisational
  computing where different nodes are located in
  different organisations.

65
Peer-to-peer architectures

• Peer to peer (p2p) systems
• are decentralised systems where computations may
  be carried out by any node in the network
• in principle, no distinction between clients are
  servers
• The overall system is designed to take advantage
  of the computational power and storage of a large
  number of networked computers
• the standards and protocols for communication are
  embedded in the application itself
• Most p2p systems have been personal systems
• E.g., for file sharing, Gnutella and Kazaa
• but there is increasing business use of this
  technology

66
P2p architectural models

• Two perspectives on p2p architectures
• The logical network architecture
• Decentralised architectures
• Semi-centralised architectures.
• Application architecture
• The generic organisation of components making up
  a p2p application.
• Focus here on network architectures.

67
Decentralised p2p architecture
68
Decentralized architectures

• In a decentralized architecture
• nodes are both functional elements and
  communication switches
• they can route data and control signals from one
  node to another
• A node
• holds data (replicas)
• answers search queries
• forwards search queries to other nodes
• routes data back to requestors
• The architecture is highly redundant

69
Semi-centralised p2p architecture
70
Semi-centralized architectures

• In a semi-centralized architecture
• one or more nodes act as servers to facilitate
  node communications
• The role of a server
• help establish contact between peers then, direct
  communications can be established
• coordinate the results of a computation

71
Service-oriented architectures

• The Web supports data/service access though web
  pages
• access is suited to human clients
• direct access from other programs is not
  practical
• Web services have the goal of providing services
  (to programs) over the web
• Service-oriented architectures are based around
  the notion of externally provided services
• web services, grid services, ...
• A web service is a standard approach to making a
  reusable component available and accessible
  across the web
• a tax filing service could provide support for
  users to fill in their tax forms and submit these
  to the tax authorities

72
A generic service

• A more general notion of service
• a service is an act or performance offered by one
  party to another. Although the process may be
  tied to a physical product, the performance is
  essentially intangible and does not normally
  result in ownership of any of the factors of
  production.
• Service provision is therefore independent of the
  application using the service.

73
Web services
74
Services and distributed objects

• Differences between the service model and the
  distributed object model
• Provider independence
• Public advertising of service availability
• Potentially, run-time service binding
• Opportunistic construction of new services
  through composition
• Pay for use of services
• Smaller, more compact applications
• Reactive and adaptive applications.

75
Services standards

• Services are based on agreed, XML-based standards
  so can be provided on any platform and written in
  any programming language.
• Key standards
• SOAP, Simple Object Access Protocol
• defines an organization for structured data
  exchange
• WSDL, Web Services Description Language
• a language for defining the interfaces of web
  services
• UDDI, Universal Description, Discovery and
  Integration
• a discovery standard to describe service
  information

76
Services scenario

• An in-car information system provides drivers
  with information on weather, road traffic
  conditions, local information etc
• This is linked to car radio so that information
  is delivered as a signal on a specific radio
  channel
• The car is equipped with GPS receiver to discover
  its position and, based on that position, the
  system accesses a range of information services
• Information may be delivered in the drivers
  specified language.

77
Automotive system
78
Key points

• Distributed systems support resource sharing,
  openness, concurrency, scalability, fault
  tolerance and transparency.
• Client-server architectures involve services
  being delivered by servers to programs operating
  on clients.
• User interface software always runs on the client
  and data management on the server. Application
  functionality may be on the client or the server.
• In a distributed object architecture, there is no
  distinction between clients and servers.

79
Key points

• Distributed object systems require middleware to
  handle object communications and to add and
  remove system objects.
• The CORBA/EJB/DCOM standards are a set of
  middleware standards that support distributed
  object architectures.
• Peer to peer architectures are decentralised
  architectures where there is no distinction
  between clients and servers.
• Service-oriented systems are created by linking
  software services provided by different service
  suppliers.