230 likes | 363 Views
CS 501: Software Engineering Fall 2000. Lecture 16 System Architecture III Distributed Objects. Administration. •. Real-Time: Software Considerations. Resource considerations may dictate software design and implementation:
E N D
CS 501: Software EngineeringFall 2000 Lecture 16 System Architecture III Distributed Objects
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
Buffering Example: CD Controller 3 4 1 2 Input block 5 Output block 6 7 Circular buffer
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.
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
Example: Transaction Monitor Transaction monitor messages processes A transaction monitor: monitors transactions, routes them across services, balances the load, restarts transactions after failure.
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
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
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.
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)
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
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 ...
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
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
IDL IDL IDL IDL IDL Object Request Broker (ORB) Objects Other Java Cobol C++ C Interface Client Server Object Request Broker
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
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
ORB: Programmer's View Client Server Invoke a on object X Invoke a on object Y Object X a Object Y a Object Request Broker
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)
ORB: System View Object implementation Implementation repository Interface repository Client Static skeletons Dynamic invocation Object adapter Dynamic invocation ORB interface Client IDL stubs Object Request Broker
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
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.