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

2. 09 October 2007Kaiser: COMS W4156 Fall 20072 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)

3. 09 October 2007Kaiser: COMS W4156 Fall 20073 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

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

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

6. 09 October 2007Kaiser: COMS W4156 Fall 20076 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

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

8. 09 October 2007Kaiser: COMS W4156 Fall 20078 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

9. 09 October 2007Kaiser: COMS W4156 Fall 20079 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

10. 09 October 2007Kaiser: COMS W4156 Fall 200710 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

11. 09 October 2007Kaiser: COMS W4156 Fall 200711 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

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

13. 09 October 2007Kaiser: COMS W4156 Fall 200713 A CORBA Component

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

15. CCM Infrastructure

16. 09 October 2007Kaiser: COMS W4156 Fall 200716 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

17. 09 October 2007Kaiser: COMS W4156 Fall 200717 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)

18. 09 October 2007Kaiser: COMS W4156 Fall 200718 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

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

20. 09 October 2007Kaiser: COMS W4156 Fall 200720 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

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

22. 09 October 2007Kaiser: COMS W4156 Fall 200722 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

23. 09 October 2007Kaiser: COMS W4156 Fall 200723 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

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

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

26. 09 October 2007Kaiser: COMS W4156 Fall 200726 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

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

28. 09 October 2007Kaiser: COMS W4156 Fall 200728 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

29. 09 October 2007Kaiser: COMS W4156 Fall 200729 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

30. 09 October 2007Kaiser: COMS W4156 Fall 200730 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

31. 09 October 2007Kaiser: COMS W4156 Fall 200731 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

32. 09 October 2007Kaiser: COMS W4156 Fall 200732 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

33. 09 October 2007Kaiser: COMS W4156 Fall 200733 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

34. 09 October 2007Kaiser: COMS W4156 Fall 200734 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

35. 09 October 2007Kaiser: COMS W4156 Fall 200735 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

36. 09 October 2007Kaiser: COMS W4156 Fall 200736 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

37. 09 October 2007Kaiser: COMS W4156 Fall 200737 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

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

39. 09 October 2007Kaiser: COMS W4156 Fall 200739 Observer Component component Observer { // The status info sink port. consumes StatusInfo info; }; // Home for instantiating observers. home ObserverHome manages Observer {}; Observer

40. 09 October 2007Kaiser: COMS W4156 Fall 200740 Observer Home component Observer { // The status info sink port. consumes StatusInfo info; }; // Home for instantiating observers. home ObserverHome manages Observer {}; Observer

41. 09 October 2007Kaiser: COMS W4156 Fall 200741 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

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

43. 09 October 2007Kaiser: COMS W4156 Fall 200743 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 (); };

44. 09 October 2007Kaiser: COMS W4156 Fall 200744 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 (); };

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

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

47. 09 October 2007Kaiser: COMS W4156 Fall 200747 A Segmented Component Executor Main segment CCM context Component specific context Component container Seg2Seg4Seg3 ExecutorLocator

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

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

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

51. 09 October 2007Kaiser: COMS W4156 Fall 200751 Example home ButtonHome manages Button { }; valuetype ButtonName : Components::PrimaryKeyBase { public string name; }; home ButtonHome manages Button primaryKey ButtonName { };

52. 09 October 2007Kaiser: COMS W4156 Fall 200752 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

53. 09 October 2007Kaiser: COMS W4156 Fall 200753 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 ( bind, resolve ), Trader Service (service types), or home finder (primary key) operations Invokes operations on component instances

54. 09 October 2007Kaiser: COMS W4156 Fall 200754 Client-Side OMG IDL Mapping Each OMG IDL 3.0 construction has an equivalent in terms of OMG IDL 2 (pre-CCM) 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

55. 09 October 2007Kaiser: COMS W4156 Fall 200755 Equivalent IDL module example { component C { … features }; module example { interface C : Components::ComponentBase { … equivalent features };

56. 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

57. Component Packaging

58. Component Deployment

59. 09 October 2007Kaiser: COMS W4156 Fall 200759 Available CCM Implementations NameProviderOpen Source LanguageURL Component Integrated ACE ORB (CIAO) Vanderbilt University & Washington University YesC++ www.dre.vanderbilt.edu/CIAO/ Enterprise Java CORBA Component Model (EJCCM) Computational Physics, Inc. YesJava www.cpi.com/ejccm/ K2 iCMG NoC++ www.icmgworld.com/products.asp MicoCCM FPX YesC++ www.fpx.de/MicoCCM/ OpenCCM ObjectWeb YesJava openccm.objectweb.org/ [website often down] QoS Enabled Distributed Object (Qedo) BerliOS Developer YesC++ developer.berlios.de/projects/qedo StarCCM Source Forge YesC++ sourceforge.net/projects/starccm/

60. 09 October 2007Kaiser: COMS W4156 Fall 200760 Next Time? More Component Models OR Traditional Software Engineering

61. 09 October 2007Kaiser: COMS W4156 Fall 200761 First Iteration Plan Due Next Week! Tuesday 16 October, 10am Assignments posted on course websitecourse website Submit via CourseWorksCourseWorks First Iteration Plan

62. 09 October 2007Kaiser: COMS W4156 Fall 200762 Upcoming Deadlines First iteration progress report due October 23 rdFirst iteration progress report First iteration demo week October 30 th – November 8 th First iteration final report due November 9 th Midterm Individual Assessment posted Friday November 9 th Midterm Individual Assessment due Friday November 16 th

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