Distributed%20Systems

1
Distributed Systems

• Topic 2
• Distributed Software Engineering Using CORBA
• Dr. Michael R. Lyu
• Computer Science Engineering Department
• The Chinese University of Hong Kong

2
Outline

• 1 Motivation
• 2 The CORBA Object Model
• 3 The OMG Interface Definition Language
• 4 Summary

3
1 Motivation

• Distributed Systems consist of multiple
  components.
• Components are heterogeneous.
• Components still have to be interoperable.
• There has to be a common model for components
  that expresses
• component states,
• component services, and
• interaction of components with other components.

4
2 The CORBA Object Model

• Components ??objects.
• Visible component state ? object attributes.
• Usable component services ? object operations.
• Component interactions ? operation execution
  requests.
• Component service failures ? exceptions.

5
2.0 Automatic Teller Machine Network
6
2.1 Types of Distributed Objects

• Attributes, operations and exceptions are
  properties objects may export to other objects.
• Multiple objects may export the same properties.
• Only define the properties once!
• Attributes and operations, and exceptions are
  defined in object types.

7
2.2 Attributes

• Attributes have a name and a type.
• Type can be an object type or a non-object type.
• Attributes are readable by other components.
• Attributes may or may not be modifyable by other
  components.
• Attributes correspond to one or two operations
  (set/get).

8
2.3 Exceptions

• Service requests in a distributed system may not
  be properly executed.
• Exceptions are used to explain reason of failure
  to requester of operation execution.
• Operation execution failures may be
• generic or
• specific.
• Specific failures may be explained in specific
  exceptions.

9
2.4 Operations

• Operations have a signature that consists of
• a name,
• a list of in, out, or inout parameters,
• a return value type, and
• a list of exceptions that the operation can raise.

10
2.5 Operation Execution Requests

• A client object can request an operation
  execution from a server object.
• Operation request is expressed by sending a
  message (operation name) to server object.
• Clients have to react to exceptions that the
  operation may raise.

11
2.6 Subtyping

• Properties shared by several types should be
  defined only once.
• Object types are organized in a type hierarchy.
• irreflexive, anti-symmetric, transitive
• Subtypes inherit attributes, operations and
  exceptions from their supertypes.
• Subtypes can add more specific properties.
• Subtypes can redefine inherited properties.

12
2.7 Problems of the Model

• Interactions between components are not defined
  in the model.
• No concept for abstract or deferred types.
• Model does not include primitives for the
  behavioral specification of operations.
• Semantics of the model is only defined informally.

13
3 The OMG Interface Definition Language

• OMG/IDL is a language for expressing all concepts
  of the CORBA object model.
• OMG/IDL is
• programming-language independent,
• orientated towards C, and
• not computationally complete.
• Different programming language bindings are
  available.

14
3.1 Types

• A type is one of the following
• Atomic types
• (void, boolean, short, long, float, char,
  string),
• Object types (interface),
• Constructed types
• Records (struct),
• Variants (union), and
• Lists (sequence), or
• Named types (typedef).

15
3.1 Types (Examples)

• struct Requester
• int PIN
• string AccountNo
• string Bank
• typedef sequenceltATMgt ATMList

16
3.2 Attributes

• Attributes are declared within an interface.
• Attributes have a type and a name.
• Attribute name must be unique within the
  interface.
• Attributes can be declared as read-only.

17
3.2 Attributes (Examples)

• readonly attribute ATMList ATMs
• readonly attribute BankList banks

18
3.3 Exceptions

• Exceptions have a unique name.
• Exceptions may declare additional data
  structures.
• These can be used to locate reasons for failures.

19
3.3 Exceptions (Example)

• exception InvalidPIN
• exception InvalidATM
• exception NotEnoughMoneyInAccount
• short available

20
3.4 Operations

• Operations have a unique identifier.
• Operations have a parameter list.
• parameters are in, out or inout,
• parameter identifiers are unique within the list,
  and
• parameter types have been declared.
• Operations have a result type.
• Operations declare exceptions they may raise.

21
3.4 Operations (Examples)

• void accept_request(in Requester req,
• in short amount)
• raises(InvalidPIN,
• NotEnoughMoneyInAccount)
• short money_in_dispenser(in ATM dispenser)
• raises(InvalidATM)

22
3.5 Interfaces

• Attributes, exceptions and operations are defined
  in interfaces.
• Interfaces have an identifier, which denotes the
  object type associated with the interface.
• Interfaces must be declared before they can be
  used.
• Interfaces can be declared forward.

23
3.5 Interfaces (Example)

• interface ATM
• interface TellerCtrl
• typedef sequenceltATMgt ATMList
• exception InvalidPIN
• exception NotEnoughMoneyInAccount ...
• readonly attribute ATMList ATMs
• readonly attribute BankList banks
• void accept_request(in Requester req,
• in short amount)
• raises(InvalidPIN,NotEnoughMoneyInAccount)

24
3.6 Modules

• A global name space for identifiers is
  unreasonable.
• IDL includes Modules to restrict visibility of
  identifiers.
• Access to identifiers from other modules by
  qualification with module identifier.

25
3.6 Modules (Example)

• module Bank
• interface AccountDB
• module ATMNetwork
• typedef sequenceltBankAccountDBgt BankList
• exception InvalidPIN
• interface ATM
• interface TellerCtrl ...

26
3.7 Inheritance

• Notation to define object type hierarchy.
• Type hierarchy has to form an acyclic graph.
• Type hierarchy graph has one root called
  (Object).
• Subtypes inherit the attributes, exceptions and
  operations of all super-types.

27
3.7 Inheritance (Examples)

• interface Controllee
• interface Ctrl
• typedef sequenceltControlleegt CtrleeList
• readonly attribute CtrleeList controls
• void add(in Controllee new_controllee)
• void discard(in Controllee old_controllee)
• interface ATM Controllee ...
• interface TellerCtrl Ctrl ...

28
3.7 Inheritance (Multiple)

• Multiple Inheritance
• May cause name clashes if different super-types
  export the same identifier.
• Example
• interface Set
• void add(in Element new_elem)
• interface TellerCtrlSet, Ctrl ...
• Name clashes are not allowed!

29
3.8 Redefinition

• Behavior of an operation as defined in a
  super-type may not be appropriate for a subtype.
• Operation can be re-defined in the subtype.
• Binding messages to operations is dynamic.
• Operation signature must not be changed.
• Operations in (abstract) super-types are often
  not implemented and used as callbacks.

30
3.8 Redefinition (Example)

• interface Ctrl
• void add(in Controllee new_controllee)
• interface TellerCtrl Ctrl
• void add(in ATM new_controllee)

31
3.9 Polymorphism

• Objects can be assigned to an attribute or passed
  as a parameter that are instances of subtypes of
  the respective static type.
• Attributes, parameters and operations are
  polymorph.
• Example
• Using Polymorphism, instances of type ATM can be
  inserted into attribute controls that TellerCtrl
  has inherited from Ctrl.

32
4.0 A Running Example
33
4.1 CORBA Object Model Types

• typedef struct _Address
• string street
• string postcode
• string city
• Address
• typedef sequenceltAddressgt AddressList
• interface Team ...

34
4.2 CORBA Object Model Modules
module Soccer typedef struct _Address
string street string postcode string city
Address module People typedef struct
_Address string flat_number string
street string postcode string city
string country Address
35
4.3 CORBA Object Model Attributes
interface Player typedef sequenceltPlayergt
PlayerList interface Trainer typedef
sequenceltTrainergt TrainerList interface Team
readonly attribute string name attribute
TrainerList coached_by attribute Club
belongs_to attribute PlayerList players
...
36
4.4 CORBA Object Model Operations

• interface Team
• ...
• void bookGoalies(in Date d)
• string print()

37
4.5 CORBA Object Model Requests

• Requests are defined by client objects
• Request consist of
• Reference of server object
• Name of requested operation
• Actual request parameters
• Context information
• Request is executed synchronously
• Requests can be defined
• statically
• dynamically

38
4.6 CORBA Object Model Exceptions

• Generic Exceptions (e.g. network down, invalid
  object reference, out of memory)
• Type-specific Exceptions

39
4.7 CORBA Object Model Subtypes
interface Organization readonly attribute
string name interface Club Organization
exception NotInClub readonly attribute
short noOfMembers readonly attribute Address
location attribute TeamList teams attribute
TrainerList trainers void transfer(in Player
p) raises NotInClub
40
5 Summary

• Why do we need a component model?
• What are the primitives of the CORBA object
  model?
• What is OMG/IDL?
• What are the strength and weaknesses of the CORBA
  approach in realizing object orientation?