03 october 2006kaiser: coms w4156 fall 20061 coms w4156: advanced software engineering prof. gail...

03 October 2006 Kaiser: COMS W4156 Fall 2006 1

COMS W4156: Advanced Software Engineering

Prof. Gail Kaiser

[email protected]

http://york.cs.columbia.edu/classes/cs4156/

mailto:[email protected]



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


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


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)


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


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/


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


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


Component Features (Ports)

• Facets = offered operation interfaces

• Receptacles = required operation interfaces

• Event sources = produced events

• Event sinks = consumed events

• Attributes = configurable properties


A CORBA Component

Component interface

OF

FE

RE

D

MyBusiness

Component

Facets

Eventsources

Eventsinks

Attributes

Receptacles RE

QU

IRE

D

Component interface

OF

FE

RE

D

MyBusiness

Component

Facets

Eventsources

Eventsinks

Attributes

Receptacles RE

QU

IRE

D

MyBusiness

Component

Facets

Eventsources

Eventsinks

Attributes

Receptacles RE

QU

IRE

D


Building CCM Applications =Assembling Component Instances


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


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


Receptacles

• Connection points between components, where one uses an interface of anothercomponent 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


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


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


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


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


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


A CORBA Component Home

MyBusinessHome

c1

…

cN

Home interface


Example

home ButtonHome manages Button {<operations>};

valuetype ButtonName : Components::PrimaryKeyBase { public string name; };

home ButtonHome manages Button primaryKey ButtonName {<operations>};


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


Dining Philosophers Example

Thinking

HungryStarvin

gEatingDead

Kant

ThinkingHungryStarvingEatingDeadDescartes

ThinkingHungryStarvingEatingDead

Aristotle

Fork

Fork

Fork


Dining Philosophers asCORBA Components

Philosopher

name = Kant

Philosopher

name = Aristotle

Philosopher

name = Descartes

Fork

Fork

Fork

Component

Base ref.

Facet

Receptacle

Event Source

Event Sink

Observer


OMG IDL 3.0 for Dining Philosophers

import Components;module DiningPhilosophers{typeprefix DiningPhilosophers "omg.org"; . . .

};


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 {};

ForkManager


Fork Manager Component






ForkManager


Fork Manager Component Facet






ForkManager


ForkHomeFork Manager Home






ForkManager


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


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


Philosopher Component Receptacles


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


Philosopher Component Receptacles


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


Philosopher Component Event Source




Philosopher

name = XXX


PhilosopherHome

Philosopher Home




Philosopher

name = XXX


Observer Component

component Observer

{

// The status info sink port.

consumes StatusInfo info;

};

// Home for instantiating observers.

home ObserverHome manages Observer {};

Observer


Observer HomeObserver Home

component Observer {// The status info sink port.consumes StatusInfo info;

};

// Home for instantiating observers. home ObserverHome manages Observer {};

Observer


Dining Philosophers asCORBA Components

Philosopher

name = Kant

Philosopher

name = Aristotle

Philosopher

name = Descartes

Fork

Fork

Fork

Component

Base ref.

Facet

Receptacle

Event Source

Event Sink

Observer


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


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


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


Equivalent IDL

module example {

component C {

… features

};

};

module example {

interface C :

Components::ComponentBase

{

… equivalent features

};

};


Client-Side OMG IDL Mapping

ComponentDesigner

User written

Compiler

Generated files

OMG IDL3.0

ClientStub

OMG IDL 3.0

CompilerClient-side

OMG IDL 2.x

ComponentClient

ClientApplication

uses

implemented by

ORBComponent


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


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


Upcoming

• Project Concept due TODAY! – Extension to Thursday October 5th only for teams that had membership changes

• Individual development assignment #3 due October 10th

• Revised project concept due October 17th

• First iteration plan due October 24th


COMS W4156: Advanced Software Engineering

Prof. Gail Kaiser

[email protected]


mailto:[email protected]


03 october 2006kaiser: coms w4156 fall 20061 coms w4156: advanced software engineering prof. gail...

Documents