1. 03 October 2006Kaiser: COMS W4156 Fall 20061 COMS W4156: Advanced Software Engineering Prof. Gail Kaiser Kaiser+4156@cs.columbia.edu http://york.cs.columbia.edu/classes/cs4156/

2. 03 October 2006Kaiser: COMS W4156 Fall 20062 CORBA Review Clear distinction between interface and implementation Server interface specified using IDL Clients request services from server objects via method invocation Server and client implementations can be done using any programming languages for which a CORBA mapping exists Allows writing platform and language independent code

3. 03 October 2006Kaiser: COMS W4156 Fall 20063 CORBA Review Object Request Broker (ORB) acts as a “mediator” that abstracts –Object location: server method invocations always local, then ORB redirects –Networking issues: stub/skeleton code automatically generated, usually programmer can ignore –Activation issues: ORB automatically activates and deactivates server objects

4. 03 October 2006Kaiser: COMS W4156 Fall 20064 CORBA Limitations [Before version 3.0, which includes “CORBA Component Model”] No support for common programming idioms –Most server objects implemented as “factories”, creating a new object instance to deal with each client, but new factory code needs to be written for each server –Every programmer has same choices to make, between persistent and transient references, objects identified by a primary key or not, objects maintain persistent state or not, … No common set of object services implemented by all ORBs No standard way of deploying server objects (adding new server objects to an ORB) –Each ORB has different approach to IMR (IMplementation Repository)

5. 03 October 2006Kaiser: COMS W4156 Fall 20065 CORBA Needs “Components” Binary (executable) units that can be used interchangeably with any ORB –Allows graceful evolution by replacing one component with another –Eases porting to another ORB (e.g., better, faster, cheaper) Applications can then be built by assembling components –Components must define what they need and what they offer –Once assembled, deployment must be semi-automatic Need standard development, deployment and runtime environment

6. 03 October 2006Kaiser: COMS W4156 Fall 20066 CORBA Component Model (CCM) Part of CORBA 3.0 specification June 2002 (and CORBA 4.0 April 2006) Extends CORBA object model –New component meta-type –Enforces composition rather than inheritance OpenCCM 0.9.0 latest release July 2005 (http://openccm.objectweb.org/)http://openccm.objectweb.org/

7. 03 October 2006Kaiser: COMS W4156 Fall 20067 Abstract Component Model Describes how CORBA components are viewed by other components and clients –What a component offers to other components –What a component requires from other components –Two collaboration modes: Synchronous via operation invocation and Asynchronous via event notification –Which component properties are configurable

8. 03 October 2006Kaiser: COMS W4156 Fall 20068 What is a CORBA Component? component is a new CORBA meta-type –extension of Object (with some constraints) –has an interface, and an object reference Provides component features (ports) –Define their possible connection graph –Define their requirements and offerings –Allow component configuration Each component instance is created and managed by a unique component home

9. 03 October 2006Kaiser: COMS W4156 Fall 20069 Component Features (Ports) Facets = offered operation interfaces Receptacles= required operation interfaces Event sources = produced events Event sinks = consumed events Attributes = configurable properties

10. 03 October 2006Kaiser: COMS W4156 Fall 200610 A CORBA Component

11. 03 October 2006Kaiser: COMS W4156 Fall 200611 Building CCM Applications = Assembling Component Instances

12. 03 October 2006Kaiser: COMS W4156 Fall 200612 Component Declaration and Supported Interface Specify a name for the component Component “supports” an interface –For use by component-unaware clients –Equivalent to interface inheritance Can convert any server object to a component

13. 03 October 2006Kaiser: COMS W4156 Fall 200613 Facets Multiple named interfaces that provide the component’s application functionality to clients - one of these must be the same as the supported interface Each facet embodies a view of the component, corresponds to a role in which a client may act relatively to the component A facet represents the component itself, not a separate thing contained by the component Facets have independent object references

14. 03 October 2006Kaiser: COMS W4156 Fall 200614 Receptacles Connection points between components, where one uses an interface of another component blahblah … { uses Embeddable dependent; }; No inherent life cycle dependencies or ownership relationship implied - no operations are inherently transitive across receptacle connection IDL compiler generates operations to connect to and disconnect from the receptacle

15. 03 October 2006Kaiser: COMS W4156 Fall 200615 Events Decoupled communication between components –Receptacle supports direct communication between components –In contrast, events are indirect: Event channel contacts set of consumers for each event Simple event model based on channels –Subject routing rather than content routing

16. 03 October 2006Kaiser: COMS W4156 Fall 200616 Event Sources Publisher is intended for 1:N client access –Client subscribes to event source directly on component –Component mediates access to event channel –Component is only source of events for channel Emitter is a simple 1:1 consumer proxy –Intended for connection to an arbitrary event channel during configuration

17. 03 October 2006Kaiser: COMS W4156 Fall 200617 Event Sinks Named connection points into which events of a specific type may be pushed Subscription to event sources –Potentially multiple (n to 1) No distinction between emitter and publisher –Both push into event sinks

18. 03 October 2006Kaiser: COMS W4156 Fall 200618 Attributes Named configurable properties Can be configured by visual property sheets Allow component configuration on an instance basis, via “configurator” objects –Attributes exposed through accessors and mutators –Signal when completed and then validity checked Determine behavior (within range of possible behaviors) for particular component instance

19. 03 October 2006Kaiser: COMS W4156 Fall 200619 Homes A home is an object that manages a set of similar components –Life cycle management –Maps key values to entity components –More than one home type can manage the same component type (but any given component instance has only one home) Encapsulate factory behavior, so each programmer doesn’t have to write it Instantiated at deployment time

20. 03 October 2006Kaiser: COMS W4156 Fall 200620 A CORBA Component Home MyBusinessHome c1 … cN Home interface

21. 03 October 2006Kaiser: COMS W4156 Fall 200621 Example home ButtonHome manages Button { }; valuetype ButtonName : Components::PrimaryKeyBase { public string name; }; home ButtonHome manages Button primaryKey ButtonName { };

22. 03 October 2006Kaiser: COMS W4156 Fall 200622 Primary Keys A primary key is a value assigned by the application that uniquely identifies a component instance in the scope of a home –Assign at create time, or in pre-existing database –Can be used to find, destroy Association between a primary key and a component is defined and maintained by a home –Primary key is not necessarily a part of the component’s state –Different home types may define different key types (or no key) for the same component type

23. 03 October 2006Kaiser: COMS W4156 Fall 200623 Dining Philosophers Example Thinking Hungry Starving Eating Dead Kant Thinking Hungry Starving Eating Dead Descartes Thinking Hungry Starving Eating Dead Aristotle Fork

24. 03 October 2006Kaiser: COMS W4156 Fall 200624 Dining Philosophers as CORBA Components Philosopher name = Kant Philosopher name = Aristotle Philosopher name = Descartes Fork Component Base ref. Facet Receptacle Event Source Event Sink Observer

25. 03 October 2006Kaiser: COMS W4156 Fall 200625 OMG IDL 3.0 for Dining Philosophers import Components; module DiningPhilosophers { typeprefix DiningPhilosophers "omg.org";... };

26. 03 October 2006Kaiser: COMS W4156 Fall 200626 Fork Interface exception InUse {}; interface Fork { void get() raises (InUse); void release(); }; // The fork component. component ForkManager { // The fork facet used by philosophers. provides Fork the_fork; }; // Home for instantiating ForkManager components. home ForkHome manages ForkManager {}; Fork Manager

27. 03 October 2006Kaiser: COMS W4156 Fall 200627 Fork Manager Component exception InUse {}; interface Fork { void get() raises (InUse); void release(); }; // The fork component. component ForkManager { // The fork facet used by philosophers. provides Fork the_fork; }; // Home for instantiating ForkManager components. home ForkHome manages ForkManager {}; Fork Manager

28. 03 October 2006Kaiser: COMS W4156 Fall 200628 Fork Manager Component Facet exception InUse {}; interface Fork { void get() raises (InUse); void release(); }; // The fork component. component ForkManager { // The fork facet used by philosophers. provides Fork the_fork; }; // Home for instantiating ForkManager components. home ForkHome manages ForkManager {}; Fork Manager

29. 03 October 2006Kaiser: COMS W4156 Fall 200629 ForkHome Fork Manager Home exception InUse {}; interface Fork { void get() raises (InUse); void release(); }; // The fork component. component ForkManager { // The fork facet used by philosophers. provides Fork the_fork; }; // Home for instantiating ForkManager components. home ForkHome manages ForkManager {}; Fork Manager

30. 03 October 2006Kaiser: COMS W4156 Fall 200630 Philosopher State Types enum PhilosopherState { EATING, THINKING, HUNGRY, STARVING, DEAD }; eventtype StatusInfo { public string name; public PhilosopherState state; public unsigned long ticks_since_last_meal; public boolean has_left_fork; public boolean has_right_fork; }; Philosopher name = XXX

31. 03 October 2006Kaiser: COMS W4156 Fall 200631 Philosopher Component component Philosopher { attribute string name; // The left fork receptacle. uses Fork left; // The right fork receptacle. uses Fork right; // The status info event source. publishes StatusInfo info;}; home PhilosopherHome manages Philosopher { factory new(in string name); }; Philosopher name = XXX

32. 03 October 2006Kaiser: COMS W4156 Fall 200632 Philosopher Component Receptacles component Philosopher { attribute string name; // The left fork receptacle. uses Fork left; // The right fork receptacle. uses Fork right; // The status info event source. publishes StatusInfo info;}; home PhilosopherHome manages Philosopher { factory new(in string name); }; Philosopher name = XXX

33. 03 October 2006Kaiser: COMS W4156 Fall 200633 Philosopher Component Receptacles component Philosopher { attribute string name; // The left fork receptacle. uses Fork left; // The right fork receptacle. uses Fork right; // The status info event source. publishes StatusInfo info; }; home PhilosopherHome manages Philosopher { factory new(in string name); }; Philosopher name = XXX

34. 03 October 2006Kaiser: COMS W4156 Fall 200634 Philosopher Component Event Source component Philosopher { attribute string name; // The left fork receptacle. uses Fork left; // The right fork receptacle. uses Fork right; // The status info event source. publishes StatusInfo info; }; home PhilosopherHome manages Philosopher { factory new(in string name); }; Philosopher name = XXX

35. 03 October 2006Kaiser: COMS W4156 Fall 200635 PhilosopherHome component Philosopher { attribute string name; // The left fork receptacle. uses Fork left; // The right fork receptacle. uses Fork right; // The status info event source. publishes StatusInfo info; }; home PhilosopherHome manages Philosopher { factory new(in string name); }; Philosopher name = XXX

36. 03 October 2006Kaiser: COMS W4156 Fall 200636 Observer Component component Observer { // The status info sink port. consumes StatusInfo info; }; // Home for instantiating observers. home ObserverHome manages Observer {}; Observer

37. 03 October 2006Kaiser: COMS W4156 Fall 200637 Observer Component component Observer { // The status info sink port. consumes StatusInfo info; }; // Home for instantiating observers. home ObserverHome manages Observer {}; Observer

38. 03 October 2006Kaiser: COMS W4156 Fall 200638 Observer Home component Observer { // The status info sink port. consumes StatusInfo info; }; // Home for instantiating observers. home ObserverHome manages Observer {}; Observer

39. 03 October 2006Kaiser: COMS W4156 Fall 200639 Dining Philosophers as CORBA Components Philosopher name = Kant Philosopher name = Aristotle Philosopher name = Descartes Fork Component Base ref. Facet Receptacle Event Source Event Sink Observer

40. 03 October 2006Kaiser: COMS W4156 Fall 200640 Client Programming Model Component-aware and -unaware clients Clients see two design patterns –Factory – Client finds a home and uses it to create a new component instance –Finder - Client searches an existing component instance through Name Service, Trader Service, or home finder operations Invokes operations on component instances

41. 03 October 2006Kaiser: COMS W4156 Fall 200641 Home Finders A brokerage of homes to clients –Home implementations register with home finder –Clients request homes from home finder Home finder makes determination of what is the “best” home to service a client, based on the client’s request and any available environmental or configuration data A home finder constitutes a domain of home/container/implementation visibility

42. 03 October 2006Kaiser: COMS W4156 Fall 200642 Client-Side OMG IDL Mapping Each OMG IDL 3.0 construction has an equivalent in terms of OMG IDL 2 Existing server objects can be converted to components Requires no changes in client programming language mapping –Clients still use their favorite IDL-oriented tools like CORBA stub generators, etc. Clients do NOT have to be “component-aware” –They just invoke interface operations

43. 03 October 2006Kaiser: COMS W4156 Fall 200643 Equivalent IDL module example { component C { … features }; module example { interface C : Components::ComponentBase { … equivalent features };

44. 03 October 2006Kaiser: COMS W4156 Fall 200644 Client-Side OMG IDL Mapping Component Designer User written Compiler Generated files OMG IDL 3.0 Client Stub OMG IDL 3.0 Compiler Client-side OMG IDL 2.x Component Client Application uses implemented by ORB Component

45. 03 October 2006Kaiser: COMS W4156 Fall 200645 Individual Development Assignment #3 due Tuesday October 10th Implement an AuctionHouse application just like for IDA#2 Same functional requirements But this time use COM+ or EJB

46. 03 October 2006Kaiser: COMS W4156 Fall 200646 IDA #3 Deliverable (archive file) Source code Output files (screen shots, traces) showing one significant system run for each of the modes –Sequence of AuctionHouse activities –Make sure to include interaction with Supplier as well as with multiple Customers 1-page README describing your implementation and instructing on how to compile, install and run it 1-page report on your findings and impressions on using COM+ or EJB

47. 03 October 2006Kaiser: COMS W4156 Fall 200647 Upcoming Project Concept due TODAY! – Extension to Thursday October 5 th only for teams that had membership changes Individual development assignment #3 due October 10 th Revised project concept due October 17 th First iteration plan due October 24th

48. 03 October 2006Kaiser: COMS W4156 Fall 200648 COMS W4156: Advanced Software Engineering Prof. Gail Kaiser Kaiser+4156@cs.columbia.edu http://york.cs.columbia.edu/classes/cs4156/