CS 501: Software Engineering Fall 2000 Lecture 16 System Architecture III Distributed Objects Administration •

Download Report

Transcript CS 501: Software Engineering Fall 2000 Lecture 16 System Architecture III Distributed Objects Administration •

CS 501: Software Engineering Fall 2000

Lecture 16

System Architecture III Distributed Objects

Administration

2

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 3

Buffering Example: CD Controller

7 Input block 6 5 4 3 2 1 Output block Circular buffer 4

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.

5

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 6

Example: Transaction Monitor

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

7

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 8

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 9

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.

10

Reuse: Objects - Characteristics

• Encapsulation. An object has a public interface that defines how other objects or applications can interact with it. methods public 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) 11

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.

Straightforward Allows type checking • Dynamic binding

or

late binding: The link is established at run time.

Flexible and extensible Complex 12

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 ...

13

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 14

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

15

Object Request Broker (ORB) C C++ Cobol

Objects

Java Other IDL IDL IDL

Interface

IDL IDL Client Server

Object Request Broker 16

Interface Definition Language module

{ ; ; ;

interface

[:] {

See next slide

}

interface

[:] { ..... } {

Naming context Define a class Define a class

17

Interface Definition Language (continued) interface

[:] { ; ; ;

Define a class

[() [

raises

exception] [

context

]; ....

[() [

raises

exception] [

context

]; ....

Define a method Define a method

} 18

ORB: Programmer's View

Client

Invoke

a

on object

X

Invoke

a

on object

Y

Server

Object

X a

Object

Y a

Object Request Broker

19

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) 20

ORB: System View

Interface repository

Client Object implementation

Implementation repository Dynamic invocation Client IDL stubs ORB interface Static skeletons Object Request Broker Dynamic invocation

Object adapter

21

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 22

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.

23