1 / 63

COMS W4156: Advanced Software Engineering

COMS W4156: Advanced Software Engineering. Prof. Gail Kaiser Kaiser+4156@cs.columbia.edu http://york.cs.columbia.edu/classes/cs4156/. CORBA Review. Clear distinction between interface and implementation Server object interface specified using IDL (Interface Definition Language)

alaire
Télécharger la présentation

COMS W4156: Advanced Software Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related