2. © Chinese University, CSE Dept. Distributed Systems / 2 - 1 Distributed Systems Topic 2: Distributed Software Engineering Using CORBA Dr. Michael R. Lyu Computer Science & Engineering Department The Chinese University of Hong Kong

3. © Chinese University, CSE Dept. Distributed Systems / 2 - 2 Outline 1 Motivation 2 The CORBA Object Model 3 The OMG Interface Definition Language 4 Summary

4. © Chinese University, CSE Dept. Distributed Systems / 2 - 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.

5. © Chinese University, CSE Dept. Distributed Systems / 2 - 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.

6. © Chinese University, CSE Dept. Distributed Systems / 2 - 5 2.0 Automatic Teller Machine Network

7. © Chinese University, CSE Dept. Distributed Systems / 2 - 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.

8. © Chinese University, CSE Dept. Distributed Systems / 2 - 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).

9. © Chinese University, CSE Dept. Distributed Systems / 2 - 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.

10. © Chinese University, CSE Dept. Distributed Systems / 2 - 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.

11. © Chinese University, CSE Dept. Distributed Systems / 2 - 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.

12. © Chinese University, CSE Dept. Distributed Systems / 2 - 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.

13. © Chinese University, CSE Dept. Distributed Systems / 2 - 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.

14. © Chinese University, CSE Dept. Distributed Systems / 2 - 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.

15. © Chinese University, CSE Dept. Distributed Systems / 2 - 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 ).

16. © Chinese University, CSE Dept. Distributed Systems / 2 - 15 3.1 Types (Examples) struct Requester { int PIN; string AccountNo; string Bank; }; typedef sequence ATMList;

17. © Chinese University, CSE Dept. Distributed Systems / 2 - 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.

18. © Chinese University, CSE Dept. Distributed Systems / 2 - 17 3.2 Attributes (Examples) readonly attribute ATMList ATMs; readonly attribute BankList banks;

19. © Chinese University, CSE Dept. Distributed Systems / 2 - 18 3.3 Exceptions  Exceptions have a unique name.  Exceptions may declare additional data structures.  These can be used to locate reasons for failures.

20. © Chinese University, CSE Dept. Distributed Systems / 2 - 19 3.3 Exceptions (Example) exception InvalidPIN; exception InvalidATM; exception NotEnoughMoneyInAccount { short available; };

21. © Chinese University, CSE Dept. Distributed Systems / 2 - 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.

22. © Chinese University, CSE Dept. Distributed Systems / 2 - 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);

23. © Chinese University, CSE Dept. Distributed Systems / 2 - 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.

24. © Chinese University, CSE Dept. Distributed Systems / 2 - 23 3.5 Interfaces (Example) interface ATM; interface TellerCtrl { typedef sequence 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); };

25. © Chinese University, CSE Dept. Distributed Systems / 2 - 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.

26. © Chinese University, CSE Dept. Distributed Systems / 2 - 25 3.6 Modules (Example) module Bank { interface AccountDB {}; }; module ATMNetwork { typedef sequence BankList; exception InvalidPIN; interface ATM; interface TellerCtrl {...}; };

27. © Chinese University, CSE Dept. Distributed Systems / 2 - 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.

28. © Chinese University, CSE Dept. Distributed Systems / 2 - 27 3.7 Inheritance (Examples) interface Controllee; interface Ctrl { typedef sequence CtrleeList; readonly attribute CtrleeList controls; void add(in Controllee new_controllee); void discard(in Controllee old_controllee); }; interface ATM : Controllee {...}; interface TellerCtrl : Ctrl {...};

29. © Chinese University, CSE Dept. Distributed Systems / 2 - 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 TellerCtrl:Set, Ctrl {... };  Name clashes are not allowed!

30. © Chinese University, CSE Dept. Distributed Systems / 2 - 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’.

31. © Chinese University, CSE Dept. Distributed Systems / 2 - 30 3.8 Redefinition (Example) interface Ctrl { void add(in Controllee new_controllee); }; interface TellerCtrl : Ctrl { void add(in ATM new_controllee); };

32. © Chinese University, CSE Dept. Distributed Systems / 2 - 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.

33. © Chinese University, CSE Dept. Distributed Systems / 2 - 32 4.0 A Running Example Team -name:string +bookGoalies() coaches 1..* Player -name:string -Number:int +book() +transfer(p:Player) Club -noOfMembers:int -location:Address Trainer -name:string Organization #name:string works for 11..* uses plays in 111..16 has 1 * +train()

34. © Chinese University, CSE Dept. Distributed Systems / 2 - 33 4.1 CORBA Object Model: Types typedef struct _Address { string street; string postcode; string city; } Address; typedef sequence AddressList; interface Team {... }; Atomic types Atomic types Object type Object type Constructed types Constructed types

35. © Chinese University, CSE Dept. Distributed Systems / 2 - 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; }; 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; }; Modules Soccer::Address People::Address

36. © Chinese University, CSE Dept. Distributed Systems / 2 - 35 4.3 CORBA Object Model: Attributes interface Player; typedef sequence PlayerList; interface Trainer; typedef sequence TrainerList; interface Team { readonly attribute string name; attribute TrainerList coached_by; attribute Club belongs_to; attribute PlayerList players;... }; interface Player; typedef sequence PlayerList; interface Trainer; typedef sequence TrainerList; interface Team { readonly attribute string name; attribute TrainerList coached_by; attribute Club belongs_to; attribute PlayerList players;... }; Attribute type Attribute name changeable Clients cannot change value Clients cannot change value

37. © Chinese University, CSE Dept. Distributed Systems / 2 - 36 4.4 CORBA Object Model: Operations interface Team {... void bookGoalies(in Date d); string print(); }; Parameter list Parameter kind Parameter type Parameter name Operation name used in requests Operation name used in requests Return types

38. © Chinese University, CSE Dept. Distributed Systems / 2 - 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

39. © Chinese University, CSE Dept. Distributed Systems / 2 - 38 4.6 CORBA Object Model: Exceptions  Generic Exceptions (e.g. network down, invalid object reference, out of memory)  Type-specific Exceptions exception PlayerBooked{sequence free;}; interface Team {... void bookGoalies(in Date d) raises(PlayerBooked); }; exception PlayerBooked{sequence free;}; interface Team {... void bookGoalies(in Date d) raises(PlayerBooked); }; Exception data Operations declare exceptions they raise Operations declare exceptions they raise Exception name

40. © Chinese University, CSE Dept. Distributed Systems / 2 - 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; }; 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; }; Inherited by Club Supertype Implicit supertype: Object Implicit supertype: Object

41. © Chinese University, CSE Dept. Distributed Systems / 2 - 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?