CS 501: Software Engineering Fall 2000

CS 501: Software EngineeringFall 2000

Lecture 16

System Architecture III

Distributed Objects

2

Administration

•

3

Real-Time: Software Considerations

Resource considerations may dictate software design and implementation:

• Low level language (e.g., C) where programmer has close link to machine

• Inter-process communication may be too slow (e.g., C fork).

• May implement special buffering, etc., to control timings

4

Buffering Example: CD Controller

Input block Output

block

12

345

67

Circular buffer

5

Continuous Operation

Many systems must operate continuously

• Software update while operating

• Hardware monitoring and repair

• Alternative power supplies, networks, etc.

• Remote operation

These functions must be designed into the fundamental architecture.

6

Example: Routers and Other Network Computing

• Interoperation with third party devices

• Support for several versions of protocols

• Restart after total failure

• Defensive programming -- must survive

=> erroneous or malicious messages

=> extreme loads

• Time outs, dropped packets, etc.

• Evolution of network systems

7

Example: Transaction Monitor

messages

A transaction monitor: monitors transactions, routes them across services, balances the load, restarts transactions after failure.

Transaction monitor processes

8

Software Reuse: Application Packages

• Package supports a standard application (e.g., payroll, user interface to Internet information, mathematical algorithms)

• Functionality can be enhanced by:

=> configuration parameters (e.g., table driven)

=> extensibility at defined interfaces

=> custom written source code extensions

9

Reuse: Object Object Oriented Languages

Example:

Java is a relatively straightforward language with a very rich set of class hierarchies.

• Java programs derive much of their functionality from standard classes

• Learning and understanding the classes is difficult.

=> Java experts can write complex systems quickly

=> Inexperienced Java programmers write inelegant and buggy programs

10

Reuse: Objects - Basic Definitions

• An object is a piece of code that owns attributes and provides services through methods.

• The methods operate on instance data owned by the object.

• A class is a collection of like objects.

11

Reuse: Objects - Characteristics

• Encapsulation. An object has a public interface that defines how other objects or applications can interact with it.

methodspublic instance data

• Inheritance. Subclasses can be derived from parent classes. They inherit or override the parents' methods and instance data.

• Polymorphism. The effect of a method can vary depending on the class that implements it (e.g., display_object)

12

Reuse: Objects - Object Binding

Binding is the linking of the software interface between two objects.

• Static binding: The interface is determined at compile or build time.

StraightforwardAllows type checking

• Dynamic binding or late binding: The link is established at run time.

Flexible and extensibleComplex

13

Reuse: Objects - Distributed Objects

Objects on separate computers interact through method calls and instance data.

Major systems:

• CORBA (Common Object Request Broker Architecture)

• Microsoft family: OLE, COM, DCOM, Active X ...

14

Desirable Properties of Distributed Objects

• Different languages and operating environments

• Reusable code: components

• Architecture can be extensible

• Future changes can be localized

• Standard tools used for client/server interactions

15

Example: Fedora IDL

A research project to explore extensibility:

-- very simple Interface Definition Language

-- powerful tools for extensions

-- interoperability, Cornell and CNRI

http://www.cs.cornell.edu/cdlrg/fedora.html

16

Object Request Broker (ORB)

ObjectsC C++ Java OtherCobol

IDL

Client Server

IDL IDL IDL IDL

Object Request Broker

Interface

17

Interface Definition Language

module <identifier>{ <type declarations>; <constant declarations>; <exception declarations>;

interface <identifier> [:<inheritance>] {

See next slide }

interface <identifier> [:<inheritance>] { ..... }{

Naming context

Define a class

Define a class

18

Interface Definition Language (continued)

interface <identifier> [:<inheritance>] {

<type declarations>; <constant declarations>; <exception declarations>;

[<op_type] <identifier>(<parameters>) [raises exception] [context]; .... [<op_type] <identifier>(<parameters>) [raises exception] [context]; .... }

Define a class

Define a method

Define a method

19

ORB: Programmer's View

Object Request Broker

Invoke a on

object X

Invoke a on

object Y

Object X

a

Object Y

a

Client Server

20

Object Request Broker (ORB)

An ORB lets objects make requests to and receive response from other objects located locally or remotely.

• Static and dynamic method invocations

• High-level language bindings

• Self-describing system

• Local/remote transparency

• Inter-ORB protocols Internet Inter-ORB Protocol (IIOP)

21

ORB: System View

Object Request Broker

Interface repository

Dynamic invocation

Client IDL stubs

ORB interface

Implementation repository

Static skeletons

Dynamic invocation

Object adapter

Client

Object implementation

22

CORBA Services

• Naming service• Event service• Concurrency control service• Transaction service• Relationship service• Externalization service• Query service• Life cycle service• Persistence service• Licensing service• Properties service• Security service• Time service

23

Distributed Objects and the System Life-Cycle

All large systems change with time.

• Dynamic binding of objects combined with polymorphism permits the addition of extra object types, incremental changes, etc. to be localized.

Development environments change with time.

• Language bindings and IIOP permit changes.

Production environments changes with time.

• Code can be reused in different environments.