CORBA Component Model

Transcription

1 CORBA Component Model Gruppe 6: Eirik Broen Therese Steensen Hanne Vibekk 1 CCM The CORBA Component Model (CCM) is a specification for creating server-side scalable, language-neutral, transactional, multi-user and secure enterprise-level applications. A typical CCM Architecture consists of CCM Containers CORBA components that run in these containers POA ORB Other CORBA services (Transactions, Security, Persistence, Events) CCM was included into the CORBA specification as of CORBA version

2 Problems with CORBA version 2.x No standard packaging or deployment facilities. Lack of support for common patterns for implementing CORBA servers and reusing code. Lack of standard Object Services (transaction, security, notification etc.) Developer does not know what services will be available on a given host-machine 3 Goals for a new model Create a distributet object model that has: An architecture for for defining components and their interaction Container framework for controlling activation, security, transactions, persistence and events binary units that can be installed and used anywhere. Automatic code generation based on common server patterns A way of reusing and combining previously wiritten code. 4 2

3 Proposed solution The Component Implementation Framework (CIF) defines the programming model for constructing component implementations. CIF includes a declarative language, called the Component Implementation Definition Language (CIDL) for describing implementations of components and component homes. It is an extension to the IDL from CORBA v.2 The CIF uses CIDL descriptions to generate programming skeletons that automate many of the basic behaviors of components, including navigation, identity inquiries, activation, state management, lifecycle management, and so on. 5 Overview 6 3

4 The Abstract Component Model Component is a meta type in CORBA an extension and specialization of the object meta type. A component type is a named collection of features described by an IDL component definition. (Bartlett, 2001) 7 The component type Each component definition has a corresponding equivalent interface A component type defines attributes and ports, which are ways to connect to the component: Facets The interfaces provided by the component Receptacles A component s references to required interfaces Event sink Connection point used to receive events Event source Connection point used to send events 8 4

5 Component declaration syntax <component_dcl> ::= <component_header> { <component_body> } <component_header> ::= component <identifier> [ <component_inheritance_spec> ] [ <supported_interface_spec> ] Primary component identifier <supported_interface_spec> ::= supports <scoped_name> {, <scoped_name> }* <component_inheritance_spec> ::= : <scoped_name> <component_body> ::= <component_export>* <component_export> ::= <provides_dcl> ; <uses_dcl> ; <emits_dcl> ; <publishes_dcl> ; <consumes_dcl> ; <attr_dcl> ; Facets Receptacles Event source Event sink <provides_dcl> ::= provides <interface_type> <identifier> Secondary component identifier(s) 9 (CORBA Components Volume I - orbos/ ) Example: Component declaration interface VideoPlayer { VideoStream play(); int fastforward(in Speed spd); int rewind(in Speed spd); }; component VCR supports VideoPlayer{ provides AudioStream audioport; provides VideoStream videoport; }; component DVD supports VideoPlayer{ provides AudioStream audioport; provides VideoStream videoport; }; Equivalent interface Facets Facets (Bartlett, 2001) 10 5

6 Component home A meta type that acts as a manager for a component instance. A component instance can only exist in the context of a home and it is managed by a single home object specified for that component type. The home interface: Provides component factory and finder operations. Specifies the life cycle managament strategy of each component. A client can access the home interface to control the life cycle of each component instance it uses the home interface can create and remove component instances. interface KeylessCCMHome { CCMObject create_component(); }; interface CCMHome { CORBA::IRObject get_component_def (); CORBA::IRObject get_home_def (); void remove_component ( in CCMObject comp); }; Returns reference to component Returns reference to Interface Repository object 11 Home Finder To use a component, a client first aquires the home interface of the component. References to available component homes can be stored in a sentralized database accessed through a HomeFinder interface. HomeFinder enables clients to aquire a reference to the home interface of a component. interface HomeFinder { }; CCMHome find_home_by_component_type (in CORBA::RepositoryId comp_repid) raises (HomeNotFound); CCMHome find_home_by_home_type (in CORBA::RepositoryId home_repid) raises (HomeNotFound); CCMHome find_home_by_name ( in string home_name) raises (HomeNotFound); 12 6

7 Component types (1) Service components Associated with one CCM Client. Lifetime is restricted to one single method call. Session components Associated with one CCM Client. Created and destroyed by the Client. Stateless or stateful. Dies when system is shut down. Similar to a Session EJB. Process components May be shared by multiple CCM Clients. Stateful can store states across multiple invocations. Represents business processes. 13 Component types (2) Entity component May be shared by multiple CCM Clients. Stateful can store states across multiple invocations. Each entity component is uniquely identified by its Primary Key. Similar to an Entity EJB. Represents entities like customer, accounts, etc. 14 7

8 CCM Container and Application server A CCM client never accesses a CORBA component directly. Any access is done through container-generated methods which in turn invoke the component s methods. Application Servers : These provide the system services like a raw execution environment, multiprocessing, loadbalancing, device access, provide naming and transaction services and make containers visible. CCM Containers : These act as the interface between a CORBA component and the outside world Clients : These make use of the CCM components for their operations. They find the CCM container that contains the component through COSNaming and create, or obtain a reference to the component's container through the component's Home Interface. They then make use of the 15 CCM Container to invoke the component methods. Two types of clients: component-aware clients and component-unaware clients. CCM Container Programming Model The container programming model is an API framework designed to simplify the task of building a CORBA application. A container encapsulates a component implementaion and provide the run-time execution environment for CORBA components. A container is a framework for integrating transactions, security, events and persistence into a component s behaviour at runtime. A container provides the following functions for its component: All component instances are created and managed at runtime by its container Containers provide a standard set of services to a component, enabling the same component to be hosted by different container implementations. 16 8

9 CCM Container Architecture (1) External API types: Define the contract between the component developer and the client. Two forms: Application interfaces Home interfaces Container API types: Define the API framework used by the component developer to specify the contract between a specific component and its container. Two forms: Internal interfaces Callback interfaces CORBA Usage Model: Define the interactions between the container and the rest of CORBA (including the POA, the ORB, and the CORBA services). The CCM defines 3 different models: Stateless Conversational Durable 17 (CORBA Components Volume I - orbos/ ) CCM Container Architecture (2) Transactions Components may support either: Self-managed transactions Container-managed transactions Security Sequrity policy is applied consistently to all categories of components. Persistence The entity container defines two forms of persistence support: Container-managed persistence Self-managed persistence Notification CORBA components use a simple subset of the CORBA notification service to emit and consume events. 18 (CORBA Components Volume I - orbos/ ) 9

10 Component server architecture A component server is a process which provides an arbitrary number of component containers: A container is created by a container manager, which is a factory for component containers, based on the descriptive information packed with the component. Each container supports a single container API type, and a specific component type. Each container includes a spezialized POA which is responsible for creating references and managing servants for the components in that container. 7 different container categories: The Service category The Session category The Process category The Entity category The EJBSession category The EJBEntity category The Empty category 19 (CORBA Components Volume I - orbos/ ) Packaging and deployment Components may be packaged and deployed. A package, in general, consists of descriptors and a set of files. The descriptors are XML files. A package may be stored separatly or may be grouped together in an archive file. Packages may be included into assembly packages which contain Customized component packages. Assembly XML descriptior

11 Packaging Tools used for packaging and deploying are referred to as RAD tools In the packaging phase These tools generate the different descriptiors which include: Software Package Descriptor (.csd) Describes contens of component software package Component Descriptor (.ccd) Technical information generated from CIDL Component Assembly Descriptor (.cad) Describes initial virtual configuration (homes, connections) Property File Descriptor (.cpf) Name/value pairs to configure attributes 21 Deployment A component may be deployd on its own or may be included in an assembly package and depoloyed as part of this assembly package. A component assembly is a set of interrelated components and component homes represented by an assembly package. It consists of a set of component packages and an assembly descriptor. The assembly descriptor specifies the components that make up the assembly, partitioning constraints, and connections. Connections are between interface ports, represented by provides and uses features and between event ports, represented by emits, produces, and consumes features

12 Deployment (2) Component and assembly packages are provided as input to a deployment tool. A deployment tool deploys individual components and assemblies of components to an installation site, usually a set of hosts on a network. Components within an assembly may be installed on a single machine or scattered across a network. Based on an assembly descriptor and user input, the deployment tool installs and activates component homes and instances; it configures component properties and connects components together via interface and event ports, as indicated in the assembly descriptor. 23 CCM and EJB To facilitate the use of a mixture of CCM and EJB components OMG has delevoped an interworking model. The model dictates how communication between an EJB component and a CCM component is implemented. An important concept is the View object which defines the mapping between a CCM container and an EJB client or vice versa. The view object has an interface called the View Interface which exposes the targets methods and converts requests from the client

13 25 Comparison Similarities with other technologies: Enterprise Java Beans (EJB) CORBA components also created and managed by homes Run in container managing system services transparently Application component servers Component Object Model (COM) Possibility of defining multiple input and output interfaces Navigation and introspection capabilities.net Multi language packaging facilities for distribution 26 13

14 Kilder CORBA Components Volume I - orbos/ UML Profile for CORBA Components Specification CORBA Component Model (CCM). Introducing next-generation CORBA The CORBA Component Model (CCM) Overview of the CORBA Component Model