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

2. CORBA Review • Clear distinction between interface and implementation • Server object interface specified using IDL (Interface Definition Language) • Clients request services from server objects via method invocation • Server object and client implementations can be done using any programming languages for which a CORBA mapping exists (and that is supported by the given ORB) Kaiser: COMS W4156 Fall 2007

3. CORBA Review • Object Request Broker (ORB) acts as a “mediator” that abstracts • Object location: client to 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 • CORBA in five minutes Kaiser: COMS W4156 Fall 2007

4. Application Interface Development & Design Deployment IDL Object “Other” Definitions Implementations Implementations IDL Language Compiler Applications Tools Stubs & Skeletons Libraries CORBA Design-Time Kaiser: COMS W4156 Fall 2007

5. CORBA Run-Time Kaiser: COMS W4156 Fall 2007

6. CORBA Limitations • 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 object • 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 services implemented by all ORB implementations • No standard way of deploying server objects Kaiser: COMS W4156 Fall 2007

7. 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 Kaiser: COMS W4156 Fall 2007

8. CORBA Component Model (CCM) • Part of CORBA 3.0 specification, June 2002 (revised in CORBA Component Model 4.0, April 2006) • Extends CORBA object model • New component meta-type • Development by composition Kaiser: COMS W4156 Fall 2007

9. Abstract Component Model • Creates a standard “virtual boundary” around application component implementations that interact only via well-defined interfaces • 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 Kaiser: COMS W4156 Fall 2007

10. Component Middleware • Defines standard container mechanisms needed to execute components in generic component servers • Specifies the infrastructure needed to configure and deploy components throughout a distributed system Kaiser: COMS W4156 Fall 2007

11. What is a CORBA Component? • component is a new CORBA meta-type • extension of server objects (with some constraints) • has an interface and an object reference • Provides component features (ports) • Defines their possible connection graph • Defines their requirements and offerings • Allows component configuration • Each component instance is created and managed by a unique component home • Technically, each component is instantiated as a component executor managed by a home executor Kaiser: COMS W4156 Fall 2007

12. Component Features (Ports) • Facets = offers (provides) operation interfaces • Receptacles = requires (uses) operation interfaces • Event sources = produced events • Event sinks = consumed events • Attributes = configurable properties Kaiser: COMS W4156 Fall 2007

13. A CORBA Component Kaiser: COMS W4156 Fall 2007

14. Building CCM Applications =Assembling Component Instances Kaiser: COMS W4156 Fall 2007

15. Component Component Reference Reference Container Container Component Component Home Home COMPONENT COMPONENT s s t t e e x l l x F F c c e e EXECUTORS EXECUTORS a a t t a a c t c t n n e p e p o o t t e e s s C C s s c c l l e e t t a e a e c c n n n n R R a a e r e r f f e e r n n r s s t t e e o o t t t t n e n e p p I I n n n n E E S S c c I I r r e e m m i v i v u v v u n n e e o o o k Callback k Callback o E E n n C C s s S S t t Interfaces Interfaces POA POA ORB Transaction Persistent Security Notification COMPONENT SERVER 1 COMPONENT SERVER 2 CCM Infrastructure

16. Component Declaration and Supported Interfaces • Specify a name for the component • Component “supports” one or more interfaces • For use by component-unaware clients • Equivalent to interface inheritance interface A {}; interface B {}; component D supports A, B {}; • Can convert any CORBA server object to a CORBA Component Model component Kaiser: COMS W4156 Fall 2007

17. Facets • Multiple named interfaces that provide the component’s application functionality to clients • 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 (there’s one component base reference) Kaiser: COMS W4156 Fall 2007

18. 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 connections • IDL compiler generates operations to connect to and disconnect from the receptacle • Can be simplex or multiplex Kaiser: COMS W4156 Fall 2007

19. 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 Kaiser: COMS W4156 Fall 2007

20. Event Sources • Publisher is intended for 1:N client access • Client subscribes to event channel • Container mediates access to event channel • Client can also connect directly to event source • Emitter is a simple 1:1 consumer proxy Kaiser: COMS W4156 Fall 2007

21. 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 Kaiser: COMS W4156 Fall 2007

22. Attributes • Named configurable properties • Can be configured in assembly/deployment environment, by homes, and/or during component initialization • Attributes exposed through accessors and mutators • Determine behavior (within range of possible behaviors) for particular component instance Kaiser: COMS W4156 Fall 2007

23. Homes • New CORBA meta-type • A home is an object that manages one type of component • Life cycle management (callback interface) • 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) • Encapsulates factory behavior (create), so each programmer doesn’t have to write it • Instantiated at deployment time Kaiser: COMS W4156 Fall 2007

24. A CORBA Component Home Home interface MyBusinessHome c1 … cN Kaiser: COMS W4156 Fall 2007

25. Fork Fork Fork Dining Philosophers Example Thinking Hungry Starving Eating Dead Thinking Hungry Starving Eating Dead Descartes Kant Thinking Hungry Starving Eating Dead Aristotle Kaiser: COMS W4156 Fall 2007

26. Component Base ref. Fork Fork Fork Philosopher Philosopher name = Descartes name = Kant Receptacle Event Sink Event Source Philosopher name = Aristotle Observer Dining Philosophers asCORBA Components Facet Kaiser: COMS W4156 Fall 2007

27. OMG IDL 3.0 for Dining Philosophers import Components; module DiningPhilosophers { typeprefixDiningPhilosophers"omg.org"; . . . }; Kaiser: COMS W4156 Fall 2007

28. Fork Interface exception InUse {}; interface Fork { void get() raises (InUse); void release(); }; // The fork component. componentForkManager { // The fork facet used by philosophers. provides Fork the_fork; }; // Home for instantiating ForkManager components. homeForkHomemanagesForkManager {}; Fork Manager Kaiser: COMS W4156 Fall 2007

29. Fork Manager Component exception InUse {}; interface Fork { void get() raises (InUse); void release(); }; // The fork component. componentForkManager { // The fork facet used by philosophers. provides Fork the_fork; }; // Home for instantiating ForkManager components. homeForkHomemanagesForkManager {}; Fork Manager Kaiser: COMS W4156 Fall 2007

30. Fork Manager Fork Manager Component Facet exception InUse {}; interface Fork { void get() raises (InUse); void release(); }; // The fork component. componentForkManager { // The fork facet used by philosophers. provides Fork the_fork; }; // Home for instantiating ForkManager components. homeForkHomemanagesForkManager {}; Kaiser: COMS W4156 Fall 2007

31. Fork Manager Fork Manager Home ForkHome exception InUse {}; interface Fork { void get() raises (InUse); void release(); }; // The fork component. componentForkManager { // The fork facet used by philosophers. provides Fork the_fork; }; // Home for instantiating ForkManager components. homeForkHomemanagesForkManager{}; Kaiser: COMS W4156 Fall 2007

32. Philosopher name = XXX Philosopher State Types enum PhilosopherState { EATING, THINKING, HUNGRY, STARVING, DEAD }; eventtypeStatusInfo { public string name; public PhilosopherState state; public unsigned long ticks_since_last_meal; public boolean has_left_fork; public boolean has_right_fork; }; Kaiser: COMS W4156 Fall 2007

33. Philosopher name = XXX Philosopher Component componentPhilosopher { 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;}; homePhilosopherHomemanagesPhilosopher { factorynew(in string name); }; Kaiser: COMS W4156 Fall 2007

34. Philosopher name = XXX Philosopher Component Receptacles componentPhilosopher { 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;}; homePhilosopherHomemanagesPhilosopher{ factorynew(in string name); }; Kaiser: COMS W4156 Fall 2007

35. Philosopher name = XXX Philosopher Component Receptacles componentPhilosopher { 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; }; homePhilosopherHomemanagesPhilosopher { factorynew(in string name); }; Kaiser: COMS W4156 Fall 2007

36. Philosopher name = XXX Philosopher Component Event Source componentPhilosopher { 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; }; homePhilosopherHomemanagesPhilosopher { factorynew(in string name); }; Kaiser: COMS W4156 Fall 2007

37. Philosopher name = XXX Philosopher Home PhilosopherHome componentPhilosopher { 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; }; homePhilosopherHomemanagesPhilosopher{ factorynew(in string name); }; Kaiser: COMS W4156 Fall 2007

38. Observer Observer Component componentObserver { // The status info sink port. consumes StatusInfo info; }; // Home for instantiating observers. homeObserverHomemanagesObserver {}; Kaiser: COMS W4156 Fall 2007

39. Observer Observer Component componentObserver { // The status info sink port. consumes StatusInfo info; }; // Home for instantiating observers. homeObserverHomemanagesObserver {}; Kaiser: COMS W4156 Fall 2007

40. Observer Observer Home Observer Home componentObserver { // The status info sink port. consumes StatusInfo info; }; // Home for instantiating observers. homeObserverHomemanagesObserver {}; Kaiser: COMS W4156 Fall 2007

41. Component Base ref. Fork Fork Fork Philosopher Philosopher name = Descartes name = Kant Receptacle Event Sink Event Source Philosopher name = Aristotle Observer Dining Philosophers asCORBA Components Facet Kaiser: COMS W4156 Fall 2007

42. Implementing Components and Homes • Component Executors • Home Executors • Run in Containers Kaiser: COMS W4156 Fall 2007

43. Component Executor • Uses internal interfaces to access container facilities (context object) local interface CCMContext { CCMHome get_CCM_home (); }; local interface SessionContext : CCMContext { Object get_CCM_object (); }; Kaiser: COMS W4156 Fall 2007

44. Component Executors • Provides callback interfaces for container to manage component instances local interface EnterpriseComponent{}; local interface SessionComponent : EnterpriseComponent { void set_session_context (in SessionContext ctx) void ccm_activate (); void ccm_passivate (); void ccm_remove (); }; Kaiser: COMS W4156 Fall 2007

45. Component Executors • External interfaces are those provided to clients • Monolithic – all component ports implemented by one class • Segmented – component ports split into several classes Kaiser: COMS W4156 Fall 2007

46. A Monolithic Component Executor Component container Component specific context Monolithic executor CCM context Component-oriented context interface Main component executor interface Container-oriented context interface Facet or event sink executor interface Context use SessionComponent or EntityComponent Container interposition Kaiser: COMS W4156 Fall 2007

47. A Segmented Component Executor Component container Component specific context Main segment Seg2 Seg3 Seg4 CCM context ExecutorLocator Kaiser: COMS W4156 Fall 2007

48. Containers • Intercept invocations on executors to manage activation, security, transactions, persistency, etc. • SessionComponent – transient components • EntityComponent – persistent components Kaiser: COMS W4156 Fall 2007

49. Component Categories • Service – stateless session, keyless • Session – conversational (stateful) session, keyless • Process – durable entity, keyless • Entity – durable entity, keyfull Kaiser: COMS W4156 Fall 2007

50. 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 Kaiser: COMS W4156 Fall 2007