03 October 2006Kaiser: COMS W4156 Fall COMS W4156: Advanced Software Engineering Prof. Gail Kaiser

03 October 2006Kaiser: COMS W4156 Fall 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

03 October 2006Kaiser: COMS W4156 Fall 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

03 October 2006Kaiser: COMS W4156 Fall 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)

03 October 2006Kaiser: COMS W4156 Fall 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

03 October 2006Kaiser: COMS W4156 Fall 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 latest release July 2005 (

03 October 2006Kaiser: COMS W4156 Fall 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

03 October 2006Kaiser: COMS W4156 Fall 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

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

03 October 2006Kaiser: COMS W4156 Fall A CORBA Component

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

03 October 2006Kaiser: COMS W4156 Fall 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

03 October 2006Kaiser: COMS W4156 Fall 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

03 October 2006Kaiser: COMS W4156 Fall 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

03 October 2006Kaiser: COMS W4156 Fall 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

03 October 2006Kaiser: COMS W4156 Fall 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

03 October 2006Kaiser: COMS W4156 Fall 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

03 October 2006Kaiser: COMS W4156 Fall 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

03 October 2006Kaiser: COMS W4156 Fall 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

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

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

03 October 2006Kaiser: COMS W4156 Fall 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

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

03 October 2006Kaiser: COMS W4156 Fall 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

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

03 October 2006Kaiser: COMS W4156 Fall 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

03 October 2006Kaiser: COMS W4156 Fall 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

03 October 2006Kaiser: COMS W4156 Fall 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

03 October 2006Kaiser: COMS W4156 Fall 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

03 October 2006Kaiser: COMS W4156 Fall 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

03 October 2006Kaiser: COMS W4156 Fall 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

03 October 2006Kaiser: COMS W4156 Fall 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

03 October 2006Kaiser: COMS W4156 Fall 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

03 October 2006Kaiser: COMS W4156 Fall 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

03 October 2006Kaiser: COMS W4156 Fall 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

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

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

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

03 October 2006Kaiser: COMS W4156 Fall 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

03 October 2006Kaiser: COMS W4156 Fall 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

03 October 2006Kaiser: COMS W4156 Fall 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

03 October 2006Kaiser: COMS W4156 Fall 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

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

03 October 2006Kaiser: COMS W4156 Fall 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

03 October 2006Kaiser: COMS W4156 Fall 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

03 October 2006Kaiser: COMS W4156 Fall 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

03 October 2006Kaiser: COMS W4156 Fall 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

03 October 2006Kaiser: COMS W4156 Fall COMS W4156: Advanced Software Engineering Prof. Gail Kaiser