0% found this document useful (0 votes)
20 views

Lecture 3

This document discusses different architectural styles for distributed systems including layered, object-based, resource-centered, and event-based architectures. It also covers middleware organization patterns like wrappers and interceptors and how middleware can be made modifiable and adaptive.

Uploaded by

Maham Imrani
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
20 views

Lecture 3

This document discusses different architectural styles for distributed systems including layered, object-based, resource-centered, and event-based architectures. It also covers middleware organization patterns like wrappers and interceptors and how middleware can be made modifiable and adaptive.

Uploaded by

Maham Imrani
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 31

Advanced Operating System

Course Code: CS 6001 / SE-6121

Architectural Styles, Middleware Organization

Engr. Dr. M. Kashif Shaikh


Instructor,
Software Engineering Department,
Sir Syed University of Engineering and Technology, Karachi. PAKISTAN
Objective
• Architectures • Middleware Organization
• Architectures Style
• Layered Architectures
• Object-based Architectures
• Resource-Centered
Architectures
• Event-based Architectures
Architectures
• The organization of distributed systems is mostly about the
software components that constitute the system. These
software architectures tell us how the various software
components are to be organized and how they should
interact.
• The organization of distributed systems is mostly about the
software components that constitute the system. These
software architectures tell us how the various software
components are to be organized and how they should
interact.
Architectures Style
• A style is formulated in terms of components, the way that
components are connected to each other, the data exchanged
between components, and finally how these elements are
jointly configured into a system.
• A component is a modular unit with well-defined required and
provided interfaces that is replaceable within its environment.
• That a component can be replaced, and, in particular, while a
system continues to operate, is important.
• Connector as a mechanism that mediates communication,
coordination, or cooperation among components.
Architectures Style

Layered Architectures

Object-based Architectures

Resource-Centered Architectures

Event-based Architectures
Architectures Style

•Layered Architectures
Architectures Style
•Layered
Communication
-Protocol: Each
Layer offers an
interface
specifying the
functions.
Architectures Style

•Application Layering : Applications can


often be constructed from roughly three
different pieces:
Application Interface Level

Processing Level

Data Level
Architectures Style
Architectures Style
• Object-based architectures: A procedure call can
also take place over a network, that is, the calling
object need not be executed on the same machine
as the called object.
• Object-based architectures are attractive because
they provide a natural way of encapsulating data
(called an object’s state) and the operations that can
be performed on that data (which are referred to as
an object’s methods) into a single entity.
Architectures Style

•Object-based architectures Style


Architectures Style

Remote object with client –side proxy.


Architectures Style
• Resource-based Architectures: As an increasing number of
services became available over the Web and the development
of distributed systems through service composition.
• One of the problems with service composition is that
connecting various components can easily turn into an
integration nightmare.
• A distributed system as a huge collection of resources that are
individually managed by components.
• Resources may be added or removed by (remote) applications.
• This approach has now been widely adopted for the Web and
is known as Representational State Transfer (REST).
Architectures Style
• There are four key characteristics of what are known
as RESTful architectures
Resources are identified through a single naming scheme

All services offer the same interface, consisting of at most four


operations(PUT, GET, DELETE, POST)

Messages sent to or from a service are fully self-described

After executing an operation at a service, that component forgets every-


thing about the caller.
Architectures Style
•Event-based Architectures: It is also known as
Publish-Subscribe Architectures.
•A large class of distributed systems have
adopted an architecture in which there is a
strong separation between processing and
coordination.
•Coordination encompasses the communication
and cooperation between processes.
Architectures Style
•Slightly adapting their terminology, make a
distinction between models along two different
dimensions, temporal and referential.
•Temporal coupling means that processes that
are communicating will both have to be up and
running.
•Referential coupling generally appears in the
form of explicit referencing in communication.
Architectures Style

Temporally Temporally
Coupled Decoupled

Referentially
Direct Mailbox
Coupled
Referentially
Decoupled Event-based Shared Data Space
Architectures Style
• When processes are temporally and referentially coupled,
coordination takes place in a direct way, referred to as direct
coordination.
• When processes are temporally decoupled, but referentially
coupled, which we refer to as mailbox coordination.
• The combination of referentially decoupled and temporally
coupled systems form the group of models for event-based
coordination.
• A well-known coordination model is the combination of
referentially and temporally decoupled processes, is shared
data space.
Architectures Style
Shared data spaces are often combined with
event-based coordination.
Architectures Style
Middleware Organization

•There are two important types of design


patterns that are often applied to the
organization of middleware: wrappers and
interceptors.
Middleware Organization
• Wrappers: A wrappers or adaptor is a special
component hat offers an interface acceptable to
a client application, of which the functions are
transformed into those available at the
component.
• Wrappers have always played an important role
in extending systems with existing components.
Middleware Organization
• If application A managed data that was needed by
application B, one approach would be to develop a wrapper
specific for B so that it could have access to A’s data.
• For N application, need to develop N × ( N − 1 ) = O(N2)
wrappers
• Broker: It is logically a centralized component that handles
all the accesses between different applications.
• Now need at most 2N = O( N ) wrappers instead of O(N2)
Middleware Organization
• Interceptors: Interceptors are a primary means for
adapting middleware to the specific needs of an
application.
• They play an important role in making middleware open.
• To make interceptors generic may require a substantial
implementation effort.
• To make matters concrete, consider interception as
supported in many object-based distributed systems.
Middleware Organization
The basic idea is simple: an object A can call a
method that belongs to an object B, while the
latter resides on a different machine than A.
Its carried out in three steps:
• Object A is offered a local interface that is
exactly the same as the interface offered by
object B. A calls the method available in that
interface.
Middleware Organization
• The call by A is transformed into a generic object
invocation, made possible through a general
object-invocation interface offered by the
middleware at the machine where A resides.
• Finally, the generic object invocation is
transformed into a message that is sent through
the transport-level network interface as offered
by A’s local operating system.
Middleware Organization
Middleware Organization
•Modifiable Middleware: The need for
adaptation comes from the fact that the
environment in which distributed applications
are executed changes continuously.
•Moreover, as the size of a distributed system
increases, changing its parts can rarely be done
by temporarily shutting it down.
•What is needed is being able to make changes
on-the-fly.
Middleware Organization
•Many designers of middleware to consider
the construction of adaptive software.
•Modifiable middleware to express that
middleware may not only need to be
adaptive, but that we should be able to
purposefully modify it without bringing it
down.
System Architecture

Centralized Organizations

Decentralized Organizations

Hybrid Architectures
Query Regarding Lecture
Email: [email protected]

You might also like