CORBA 1

Distributed Software Systems Any software system can be physically

distributed By distributed coupling we get the

following: Improved performance & fault tolerance Localized computation at point of use Resource availability is localized Maximum concurrency

CORBA 2

Distributed Software Systems Breaking a system into distributed

specialized components forces you to have: High cohesion within components Loose coupling between them

Distribution gives specialization DBMS on a hardware optimized machine Presentation components not tied to heavy

load computation (DBMS) Business logic can be treated as a separate

set of servicesTiers!!

CORBA 3

Distributed Components Components are designed to offer a set of

services These services form the components

interface Other components use this interface

independent of the location of the component (local or remote)

CORBA 4

Evolution of Distribution Distributed systems arise naturally from the

structure and process of a business Geographic separation Legacy integration Merger, acquisition

The supporting technology has matured Faster networks Higher level protocols & APIs Use of Internet and Intranet Client/Server

CORBA 5

Evolution of Distribution Enterprise solutions are needed to support

new management structures Technology was initially used to automate

manual processes The redesign of company structure and

work practice is aimed at adding value Legacy backbone must be used (cost) so

we need system that can integrate and migrate

Hence the growth of distributed computing

CORBA 6

Consequences of Distribution Operations execution is no longer trivial

Failure modes more complex than local cases Communication can dominate computation

All activities are intrinsically concurrent The ratio of communication to computation

is a major factor that must be considered in the architecture

The ANSA (Advanced Network System Architecture) lists some inappropriate assumption for distributed systems

CORBA 7

ANSA Inappropriate Assumptions Global Shared Memory

Message passing, distributed memory Sequential Execution

Concurrency is intrinsic Total Failure

Components can continue to function Synchronous Interaction

Network latency may force use of synchronous calls Locality of Interaction

Interaction local or remote, with increased scope for failure

Fixed Location Components may migrate

Global Consistency

CORBA 8

Principles of Distribution Previous research has identified principles and

architectures (ANSA, ISO) Reference models are frameworks for

development OSI 7 layer model ODP viewpoint and projections

FTP at Application, RPC at Session, TCP at Transport etc

Open Distributed Processing (ODP) is a reference model that defines concepts for distributed development

CORBA 9

Transparency Mechanisms We need transparency to reduce development

complexity This can simplify both the job of the architect and the

implementer To achieve transparency support is required at

every stage Infrastructure and Architecture Design and Implementation

The aim of transparency is to mask districted phenomenon (systems are never completely seamless)

CORBA 10

Transparency Mechanisms Access

Access to local and remotes services must be the same Location

No knowledge of where a service resides is needed Replication

For performance service replication may be necessary Failure

Faults don’t propagate through the entire system

CORBA 11

Transparency Mechanisms Migration

Movement of services does not impact applications

Scalability Performance must scale with size

Transaction Services can be shared without interference

from other client No partial states. A transaction is an atomic

unit of work

CORBA 12

Programming Distributed Systems Different abstraction levels available for

programming Lower level: More control but more complexity Higher Level: Closer to problem domain but

potentially inflexible and/or propriety

Application

….

Transport

….

Physical

Application

….

Transport

….

Physical

Client Server

CORBA 13

Programming Distributed Systems Inter-Processor communication happens

at the physical layer Ideal programming layer is the application

layer Programmers deal with the abstraction of

business objects and moves down to implement sockets etc

This level (layer 3,4) is not suitable for the high level abstractions and introduces too much complexity for developing the entire application here

CORBA 14

Programming Distributed Systems In theory the lower layers should be

encapsulated In practice this is not achievable so

specialist programmers for the relevant layers are required

This leads to the requirement for much integration testing

The distributed computing model tries to provide a simple and uniform model for communication to directly address the needs of the developers at each layer

CORBA 15

Distribution Mechanisms Middleware is the software used to enable

distributed computing It is a set of common business-unaware

services and allow components to interact over a network

Often referred to as the “plumbing” Middleware should make networks

irrelevant to applications and end users Solely a technology product: transaction

managers, message querying systems etc

CORBA 16

RPCs Extends the concept of a basic function

call Layered onto of an underlying transport

system such as TCP/IP Convenient methods for implementing

client/server applications Used for message passing Powerful feature of RPC is transparency Foundation for full enterprise and scalable

distributed systems

CORBA 17

Distributed Object Systems Object technology can be applied

Tactically Strategically

Objects are encapsulated entities that interact by passing messages through defined interfaces Intrinsic properties makes objects ideal for

distribution Refinements and clarifications still tend to be

needed

CORBA 18

Distributed Object Systems Encapsulation makes object suitable for

distribution The separation of interface and

implementation means interaction can only take place in ways determined by the developer

With distributed systems there is also no access to the actual representation

CORBA 19

Distributed Object Systems A good OO design allows for the

separation of visual, business and technical components

Distribution simply allows these components to be placed on the most suitable hardware available without having to alter the application (in theory)

CORBA 20

Distributed Object Technologies Different standards available

OMG CORBA (from previous work with disparate systems)

Microsoft DCOM (network COM) Java RMI (homogenous components with

JVMs) Each technology has its own origins,

strengths and area of application Distributed object model offers finer

granularity than RPC model

CORBA 21

Distributed Object Technologies The tasks of the selected middleware

technology are: Locate available objects Route messages independent of network,

operating systems and languages Transaction handling across objects

Therefore different standards have developed to achieve these tasks

CORBA 22

Classes of Distributed Support Services Distributed presentation services Distributed processing services Remote data access service Remote file access service Distributed data management Distributed object management services

CORBA 23

Summary Distribution is intrinsic in many systems

and needs to be exploited References models provide guidelines and

common concepts at every level Flexibility and open standards are required

to build seamless heterogeneous systems Distributed objects are the obvious

evolution of OO systems