Software Design and Architecture

By: Ashenafi C. and Amsalu T.

AASTU, April 2020

1
Chapter Three

Architectural Styles

2
 Architectural Styles
 An architectural style is a description of component and
connector types and a pattern of their runtime control and/or
data transfer.
 An architectural style is a named collection of architectural
design decisions that:
» are applicable in a given development context,
» constrain architectural design decisions that are specific to a particular
system within that context, and
» bring beneficial qualities in each resulting system.
 Useful in determining everything from subroutine structure to
top-level application structure.

3
 Properties of Architectural Styles
 A vocabulary of design elements
» Component and connector types; data elements
» e.g., pipes, filters, objects, servers
 A set of configuration rules
» Topological constraints that determine allowed compositions of
elements.
» e.g., a component may be connected to at most two other components.
 A semantic interpretation
» Compositions of design elements have well-defined meanings.

4
Common Architectural Styles

5
 1. Language Based Styles
 These styles are influenced by the languages that implement
them.
 They are lower-level and very flexible.
 Arch. styles in this category include:
» Main Program & Subroutine
» Object Oriented Style

6
 Object-Oriented Style
 Components are objects.
» Data and associated operations.
 Connectors are messages and method invocations.
 Style invariants/features.
» Objects preserve their internal representation (hides local data).
» Internal representation is hidden from other objects.
 Advantages:
» Since an object hides its representation from its clients, changing its
implementations without affecting those clients is possible.
» System decomposition into sets of interacting agents.
 Disadvantages:
» Objects must know identities of other objects they want to interact with.
» If identity of an object changes, it’s necessary to modify other objects
that explicitly invoke it. 7
 2. Layered Style
 Layered systems are hierarchically organized providing services to upper
layers and acting as clients for lower layers.
 Each layer exposes an interface (API) to be used by above layers.
 Lower levels provide more general functionality to more specific upper
layers.
 Each layer acts as a:
» Server: service provider to layers “above”
» Client: service consumer of layers “below”
 Connectors are protocols of layer interaction
 Application areas for this kind of style are: layered communication
protocols - OSI model, operating systems and database systems.

8
 Cont’d
 Advantages:
» They support design based on increasing abstraction levels
» Evolvability
» Changes in a layer affect at most the adjacent two layers
» Reuse
» Different implementations of layer are allowed as long as interface is preserved
» Standardized layer interfaces for libraries and frameworks
 Disadvantages:
» Not universally applicable – not all systems are easily structured in a layered fashion.
» Performance may require high coupling between high level functionality of layers and its
lower level implementation.
» Determining the correct abstraction level may be difficult.
 Architectural Styles in this category are:
» Virtual Machine
» Client-Server Architecture

9
 Client-Server
 The application is modeled as a set of services that are
provided by servers and a set of clients that use these
services.
 Clients communicate with server, which performs actions and
returns data.
 Client initiates communication.
 Components are clients and servers.
 Servers do not know number or identities of clients.
 Clients know server’s identity.
 Connectors are RPC-based network interaction protocols.

10
 Layers of Client Server
 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 management layer
» Concerned with managing the
system databases.

11
 Types of Client-Server Arch. Style
 Two-tier
» The three application layers are mapped onto two computer systems –
the client and the server.
 Client can be
» Thin client; or
» Fat client
 Three-tier
» The three application layers are mapped onto three logically separate
processes that executes on different processors.

12
Cont’d

13
 Thin Client Model
 In a thin-client 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.
 Used 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.
 A major disadvantage is that it places a heavy processing load
on both the server and the network.

14
 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.
 More processing is delegated to the client as the application
processing is locally executed.
 Most suitable for new C/S systems where the capabilities of
the client system are known in advance.
 More complex than a thin client model especially for
management. New versions of the application have to be
installed on all clients.

15
 Cont’d
 Three tier ( 3-tier) Client Server Architecture

16
 3. Data Flow Style
 A data flow style is one in which:
» The availability of data controls computation.
» The structure of the design is determined by the orderly motion of data
between components.
 The pattern of data flow is explicit.
 Architectural styles in this category are:
» Batch/Sequential
» Pipe and filter

17
 Pipe and Filter
 Components are filters
» Transform input data streams into output data streams
» Possibly incremental production of output
 Connectors are pipes
» Conduits for data streams
 Style invariants
» Filters are independent (no shared state)
» Filter has no knowledge of up-or down-stream filters
 Examples:
» UNIX shell
» Signal processing
» Distributed systems
» Parallel programming 18
 Cont’d
 Variations/types
» Pipelines — linear sequences of filters
» Bounded pipes — restricts the amount of data on a pipe
» Typed pipes — restricts the data that passes between filters has well defined type
 Advantages:
» System behavior is a succession of component behaviors
» Filter addition, replacement, and reuse
» Possible to connect any two filters together
» Certain analyses
» Throughput, deadlock
» Concurrent execution
 Disadvantages:
» Batch organization of processing
» Not suitable for interactive applications
» Loss of performance because of data transmission

19
 4. Shared State/Repository Style
 This style is characterized by a central store that represents
system state and a collection accessed and modified by a
collection of components.
 Central store is explicitly designed and structured.
 Styles under this category are:
» Blackboard
» Rule-based

20
 Blackboard Style
 Two kinds of components
» Central data structure — blackboard
» Components operating on the blackboard
 System control is entirely driven by the blackboard state.
 Examples:
» Typically used for AI systems
» Integrated software environments (e.g., Interlisp)
» Compiler architecture

21
 5. Implicit Invocation Style
 Event announcement instead of method invocation
» “Listeners” register interest in and associate methods with events
» System invokes all registered methods implicitly
 Component interfaces are methods and events
 Two types of connectors
» Invocation is either explicit or implicit in response to events
 Style invariants
» “Announcers” are unaware of their events’ effects
» No assumption about processing in response to events

22
 Cont’d
 Advantages:
» Component reuse
» System evolution
– Both at system construction-time & run-time
 Disadvantages:
» Counter-intuitive system structure
» Components relinquish computation control to the system
» No knowledge of what components will respond to event
» No knowledge of order of responses

23
 Publish-Subscribe
 Subscribers register/deregister to receive specific messages or specific
content.
 Publishers broadcast messages to subscribers either synchronously or
asynchronously.
 Components: Publishers, subscribers, proxies for managing distribution.
 Connectors: Typically a network protocol is required. Content-based
subscription requires sophisticated connectors.
 Data Elements: Subscriptions, notifications, published information.
 Topology: Subscribers connect to publishers either directly or may receive
notifications via a network protocol from intermediaries.
 Qualities yielded Highly efficient one-way dissemination of information with
very low-coupling of components.

24
 6. Peer-to-Peer Style
 State and behavior are distributed among peers which can act as either
clients or servers.
 Peers: independent components, having their own state and control
thread.
 Connectors: Network protocols, often custom.
 Data Elements: Network messages
 Topology: Network (may have redundant connections between peers);
can vary arbitrarily and dynamically
 Supports decentralized computing with flow of control and resources
distributed among peers.
 Highly robust in the face of failure of any given node.
 Scalable in terms of access to resources and computing power.

25
 Middleware Architectures
 Distributed systems have become increasingly popular and
important in modern computing.
» Provide opportunities for increasing the reliability, availability and
performance of applications.
» It also allows the integration of existing systems.

 A distributed system comprise components written in a

number of different programming languages, running on
different operating systems on a variety of computer
architectures.
 Therefore, it needs to have a single common development
and runtime environment or a middleware.

26
 Cont’d
 Middleware:
» Layer between OS and distributed applications.
» Hides complexity and heterogeneity of distributed system.
» Bridges gap between low-level OS communications and programming
language abstractions.
» Provides common programming abstraction and infrastructure for
distributed applications.

 This significantly reduces the burden on application

programmers by relieving them of this kind of tedious and
error-prone programming.

27
Cont’d

28
 Cont’d
 Middleware frameworks are designed to mask some of the
kinds of heterogeneity that programmers of distributed
systems must deal with.
 An operating system is “the software that makes the hardware
useable.”
 Similarly, middleware can be considered to be the software
that makes a distributed system programmable.
 Just as a bare computer without an operating system could be
programmed with great difficulty, programming a distributed
system is in general much more difficult without middleware,
especially when heterogeneous operation is required.

29
 Cont’d
 Middleware brings its own set of problems to the development
of distributed systems.
» More software has to be purchased, installed, tested, maintained and
learnt by developers.
» In many situations, may be unnecessary or even undesirable.
» Real time applications often require strict guarantees regarding the
bandwidth used and time taken by communications that many
middleware systems are unable to provide.
» The marshalling code generated by middleware systems may not be
as efficient as code written by the programmer.

30
 Middleware Categories
 Transactional
 two-phase commit for distributed transactions
 e.g., IBM’s CICS
 Message-oriented (MOM)
 communication via message exchange
 e.g., Sun’s JMS
 Procedural
 remote procedure calls as the foundation
 e.g., DCE RPC
 Object-based
 communication among and via distributed objects
 e.g., CORBA, COM
 Component-based
 support for distributed components
 e.g., EJB

31
 CORBA
 A middleware platform that supports a standardized OO
architecture for software applications.
» Common Object Request Broker Architecture
» Open standard - developed by the Object Management Group
» CORBA is a component of OMG’s Object Management Architecture
 OMG is the world’s largest software consortium with more than
800 member organizations.
» Its mission is to establish industry guidelines and object management
specifications to provide a common framework for distributed
application development.
 CORBA supports distributed object computing.
 CORBA uses a broker.
» an intermediary handling requests in a system.
» facilitates communication between clients and server objects.
» separates a component’s interface from its implementation. 32
 Cont’d
 CORBA’s strong points is that it is distributed middleware.
 It allows applications to talk to each other even if the
applications are:
» On different computers, for example, across a network.
» On different operating systems including Windows, UNIX, IBM
mainframes and embedded systems.
» On different CPU types, for example, Intel, SPARC, PowerPC, big-
endian or little-endian, and different word sizes, for example, 32-bit and
64-bit CPUs.
» Implemented with different programming languages, such as, C, C++,
Java, Smalltalk, Ada, COBOL, PL/I, LISP, Python and IDLScript1.

33
 CORBA’s Enhancements to Client/Server
 Extends distributed computing paradigms, such as DCE RPC,
to distributed object computing.
 Object-oriented client/server computing adds OO features to
the basic distribution idea: interfaces, messages, inheritance,
and polymorphism.
 In CORBA terminology, a server is a process that contains
objects, and a client is a process that makes calls to objects.
 A CORBA application can be both a client and a server at the
same time.
 Both synchronous and deferred synchronous
communication.
 deferred synchronous ~ asynchronous
34
 Main CORBA Features
 Object Request Broker (ORB)
 OMG Interface Definition Language (IDL)
 Stubs and Skeletons
 Interface Repository (IR)
 Static and Dynamic Invocation Interface
 Object Adapters
 Internet Inter-ORB Protocol (IIOP)

35
CORBA Architecture

36
 Object Request Broker (ORB)
 The ORB, which is the heart of CORBA, is responsible for all
the mechanisms required to perform tasks:
» Find the object implementation for the request.
» Prepare the object implementation to receive the request.
» Communicate the data making up the request.
 Requests on an object are made using its reference.
 The ORB hides object,
» Location
» Implementation
» Execution state
» Communication mechanisms.

37
 Cont’d
 The client is the entity that wishes to perform an operation
on the object, and the object implementation is the actual
code and data that implements the object.
 Both the client and the object implementation are isolated
from the ORB by an IDL interface.
 All requests are managed by the ORB.
» Every invocation (whether it is local or remote) of a CORBA object is
passed to an ORB.
» In the case of a remote invocation, however, the invocation passed
from the ORB of the client to the ORB of the object implementation.

38
 OMG Interface Definition Language
(IDL)

 The IDL defines the types of objects by defining their

interfaces.
 An interface consists of a set of named operations and the
parameters to those operations.
 Specifies implementation-independent object interface.
» It describe interfaces only, not implementations.
 Basic types:
» short, long, long long, float, double, long double, char, wchar, boolean,
octet, enum, string, wstring, etc.
 Constructed types
» struct, union, array, sequence
 IDL is language-independent
» Standardized language mappings for C, C++, Ada95, COBOL,
Smalltalk, Java. 39
 Stubs and Skeletons
 Used in CORBA’s static invocation.
 Programming language-specific counterparts to IDL
definitions.
» Stubs and skeletons are generated using the IDL definitions.
 Stubs create and issue requests on the client side.
» a.k.a. surrogates or proxies.
» Perform marshalling of requests.
 Skeletons receive and forward requests to objects on the
server side.
» Perform unmarshalling of requests.
» Return results via the server and client ORBs to the stub.

40
 Example of Stubs and Skeletons
Interface Definition
interface Employee {
void promote(in char new_job_class); void
dismiss(in DismissalCode reason,
in String description);
};

Client Application Server Application

Object Reference Object Implementation

Operation Method
promote Emp_promote

Operation Method
dismiss Emp_dismiss

41
 Static Method Invocation

 Define object classes using IDL.

 Run IDL file through language pre-compiler.
 Add implementation code to skeletons.
 Compile code.
 Bind class definitions to Interface Repository.
 Register the run-time objects with Implementation Repository
 Instantiate the objects on the server.

42
 Interface Repository
 Used for performing operations on objects whose interface is
not known at compile time.
 Knowing interfaces of all objects a priori may be impractical.
» independently developed components
» fast changing parts of the system
» dynamic manipulation
 IR allows access to the IDL type system at runtime.
» IR is a CORBA object whose functionality is invoked like any other
object.
» allows CORBA’s dynamic invocation.
 Not to confuse with Implementation Repository that contains
information for locating and activating objects.

43
 Dynamic Method Invocation
 Obtain interface name from Interface Repository.
 Obtain method description from Interface Repository.
 Create argument list.
 Create request.
 Invoke request.
 Dynamic vs. static invocation
» harder to program
» less robust type checking
» slower (factor of 40)
» harder to understand/document

44
CORBA Services (COS)

45
 Object Adapters
 The component that an object implementation uses to make
itself available for remote calls.
 The ORB uses the adapter to manage the run-time
environment of the object.
 Create and translate object references.
 Activate and deactivate object implementations.
 Basic Object Adapter (BOA)
 Portable Object Adapter (POA)

46
 Internet Inter-ORB Protocols
(IIOP)
 There is more than one CORBA implementation.
 These implementations are from different vendors.
 All CORBA 2.0 (and above) compliant ORBs are able to
interoperate via the Internet Inter-ORB Protocol, or IIOP.
 Its purpose is to ensure that your client will be able to
communicate with a server written for a different ORB from a
different vendor.
 An object oriented protocol that allows remote applications to
communicate via the Internet.

 Built on top of TCP/IP.

47
 Cont’d

Servant
Client (Server)
App. / Applet

Skeleton
IDL
Stub
POA

ORB IIOP ORB

Client Call
Return Value

48
 Reading Assignment
 Component Object Model (COM/DCOM)

49