Understanding Middleware and CORBA: Application Architectures and Object Request Brokers, Study notes of Computers and Information technologies

An overview of middleware, its role in distributed applications, and the specific case of corba. It covers various application architectures, the concept of an object request broker (orb), and the benefits of using corba for interoperability. Based on lectures by richard anthony from the university of greenwich.

Typology: Study notes

2010/2011

Uploaded on 09/10/2011

aristocrat
aristocrat 🇬🇧

5

(5)

240 documents

1 / 34

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
1111
Systems Programming
Distributed Objects
Middleware
CORBA
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19
pf1a
pf1b
pf1c
pf1d
pf1e
pf1f
pf20
pf21
pf22

Partial preview of the text

Download Understanding Middleware and CORBA: Application Architectures and Object Request Brokers and more Study notes Computers and Information technologies in PDF only on Docsity!

Systems Programming

Distributed Objects

Middleware

CORBA

Middleware – Overview

Systems Programming

Richard Anthony, Computer Science, The University of Greenwich

Client Server is a popular (2 – tier) model for distributed applicationsarchitecture – it has some limitations:

Client needs to find the server (binding)

Limited transparency (location, access, migration)

Other models include:

3 – tier

Distributed objects

Middleware is a common way to provide:

Transparency

Interoperability (platform, language independence)

Developer tools / API

Systems Programming

Richard Anthony, Computer Science, The University of Greenwich

Secondary storage

Two-tier application (fat client)

Data

Network

Presentation

Processing

Remote Data Access

Middleware – Application architectures 2

Systems Programming

Richard Anthony, Computer Science, The University of Greenwich

Secondary storage

Two-tier application (fat server)

Data

Network

Presentation

Remote Procedure call

Processing

Middleware – Application architectures 3

Systems Programming

Richard Anthony, Computer Science, The University of Greenwich

Middleware – Application architectures 5

Process

Middleware

Process

Middleware as a logical layer ‘connecting’ processes across the system

Physical network

Logical path.

Middleware

deals with complexity.

Systems Programming

Richard Anthony, Computer Science, The University of Greenwich

CORBA viewed as a three-tier architecture

Network Network

Clientobject

Clientobject

Clientobject

Object Request broker

Method

Invocation

Request

‘Service’

object

‘Service’

object

‘Service’

object

MethodInvocation

Middleware – Application architectures 6

Middleware – Complexity of distributed application development

Systems Programming

Richard Anthony, Computer Science, The University of Greenwich

Inherent complexity:

Communication latency

Detecting and recovering from partial failures of networks

Detecting and recovering from partial failures of hosts

Service partitioning (e.g. client/server split)

Replication, concurrency and consistency control

Consistent ordering of distributed events

Extensibility issues

Accidental complexity:

Continuous rediscovery and reinvention of core concepts and components (including operating systems and device drivers)

Lack of a single common design/development methodology

Inadequate debugging support (much more complicated in distributed systems)

Lack of system call interfaces and component libraries that are type-safe, portable, re-entrant and extensible

Middleware – Object Request Broker overview

Systems Programming

Richard Anthony, Computer Science, The University of Greenwich

The Object Request Broker (ORB) is the central component of CORBA

Client

Object

Implementation

ORB

Request

A request being sent through the Object Request Broker

(A High-level representation)

Middleware – Interaction between ORB and other CORBA components

Systems Programming

Richard Anthony, Computer Science, The University of Greenwich

The structure of the ORB interfaces

Client

Object

Implementation

ORB

CORE

Dynamic Invocation

IDL

Stubs

ORB

Interface

Object Adapter

IDL

Skeleton

ORB-dependent interfaceInterface identical for all ORB implementationsThere are stubs and a skeleton for each object typeThere may be multiple Object Adapters

Up-call interface

Normal call

interface

Middleware – ORB continued

Systems Programming

Richard Anthony, Computer Science, The University of Greenwich

Objects use the ORB to make requests to, and receive responses from, otherobjects. Objects are peers. Any specific object can either request information(the Client role) or respond to a request (the Server role) at any time.Each CORBA object has an object reference which is unique andindependent of its name(s).An object references another object by specifying an operation name, thetarget object reference and zero or more parameters.Additionally a request context can be passed to give data about the nature ofthe request which may effect performance of the request (thus a requestcontext supports

polymorphism

Uses of Polymorphism include:

ComputeInterest ( bank_account_ID,

bank_account_type

ComputeArea ( object_ID,

shape_indicator

There are three classes of request parameter: ►

IN (from client to server)

OUT (from server to client)

IN/OUT (can pass both ways)

Contextualise theoperation, e.g.different algorithmneeded for Area,depends on shape

Middleware – CORBA Object Adapter (example)

Systems Programming

Richard Anthony, Computer Science, The University of Greenwich

Object Adapter mechanism

Robot Control

(example application)

Client

Server

Object Adapter

Arm Position and

Control Skeleton

Rotate-

Wrist-Joint

method

Arm Position and Control

Object implementation

Network

  1. Activate implementation2. Register implementation3. Activate object
    1. Invoke

Rotate-

Wrist-Joint

method

Rotate-Wrist-Joint()

request

Requesting

object

Middleware – CORBA’s Interface and Implementation repositories

Systems Programming

Richard Anthony, Computer Science, The University of Greenwich

The

Implementation repository

(essentially a database) is used by the

Object Adapter to keep track of classes and their runtime instances(Objects).I.e. Where are objects classes stored, and where are instantiated objectsrunning. The

Interface repository

(also a database) is a runtime database that

contains descriptions of the methods associated with each class. Thisdatabase is used by the Dynamic Invocation utility to match a suitable serverobject to a dynamic request message.I.e. What methods are available, and what are their prototypes (whatparameters are needed).

Middleware – CORBA interoperability and communications

Systems Programming

Richard Anthony, Computer Science, The University of Greenwich

TCP
IP

Internet Inter-Orb Protocol (IIOP)

General Inter-Orb

Protocol (GIOP)

Environment Specific

Inter-Orb Protocol (ESIOP)

CORBA

Applications (business logic)

CORBA API calls

Application

Objects

Middleware

(including support for

communication)

Network

communication

between

computers

Middleware – ‘Static Invocation’ in CORBA - 1

Systems Programming

Richard Anthony, Computer Science, The University of Greenwich

Static Invocation

Platform 1(Client)

Application 1

Object A

Platform 2

(Server / object implementation)

Application 2

Object B

DynamicSkeleton Invocation

Dynamic Invocation

Client

IDL Stubs

Server

IDL Stubs (Skeletons)

Interface repository

Implementation

repository

ORB (Client side)

ORB (Client side)

Object Adapter

Object Request Broker (Core)

Request