CORBA Components orbos981202

1
CORBA Componentsorbos/98-12-02

• Edward Cobb, BEA Systems, Inc.
• orbos/99-01-08
• January 12, 1999

2
Agenda

• Objectives and Current Participants
• Overview of CORBA Components
• Abstract Model
• Packaging Model
• Container Model
• Meta-Model
• What Needs to be Done
• Motions

3
What is CORBA Components?

• A server-side component model for building and
  deploying CORBA applications
• An architecture for defining server components
  and their interactions
• A packaging technology for deploying binary,
  multi-lingual, executables
• A container framework for injecting security,
  transactions, events, and persistence
• A CORBA container for Enterprise JavaBeans

4
Submission Team

• BEA Systems
• DSTC
• Expersoft
• IBM
• Inprise
• Iona
• Oracle
• Rogue Wave
• Unisys

• PLUS
• Sun Microsystems

5
Model -Whats Changed Since November

• Completed Event Model including integration with
  the Container
• Completed all IDL generated by component
  declaration
• Removed storage declaration pending PSS decision
• Improved level of specification

6
Basic Concepts

• Component is a new meta-type in the CORBA typing
  system
• component types are described in IDL (with some
  new extensions), represented in Interface
  Repository (if we can still call it that)
• stylized, constrained implementation of one or
  more CORBA interfaces
• maps to generated IDL and server-side
  implementation framework based on POA

7
Component Structure
component reference supports component interface
provided references support provided interfaces
Implementations of provided interfaces are local,
encapsulated
8
Component Features

• Provided interfaces
• Used interfaces
• Events
• Configuration interface
• Home interface

9
Provided interfaces

• Independent object references
• Navigation through component interface or
  component base interface
• Presentation of components functional interface
  to client

10
Navigation

• Operation added to CORBAObject to obtain
  associated interface ComponentsComponentBase
  get_component()
• Returns nil if object reference isnt part of a
  component (i.e., a provided interface)
• Returns object reference of component interface
  if target reference belongs to component

11
Navigation

• Component interfaces derive from Navigation
• Provided interfaces may optionally derive from
  Navigation, allowing one-step navigation to any
  other provided interface

12
Component Inheritance

• Component types may singly inherit other
  component types
• Associated interfaces inherit from component base
  interface
• generic navigation, accessors
• component description

13
Used Interfaces (Dependencies)

• Different perspectives
• set during initialization/configuration to
  construct an assembly or provide dependencies on
  container
• managed at run time to provide interactions with
  clients and other components (e.g., callbacks,
  event notification)

14
Events

• Components can emit and consume events
• Simple programming model
• Event delivery mechanism and quality of service
  mediated by container
• Interoperable with CORBA notification

15
Attributes

• We abandoned the notion of a separate property
  declaration
• Instead, we added exceptions to attributes and
  provided a special configuration interface

16
Configuration Interface

• Special interface declared within scope of
  component
• Intended to hold configuration attributes,
  operations, connection points (uses)
• not generally exposed to application clients
• generally assumed to be set during initialization
• Component implementation can enforce
  serialization of configuration and application use

17
Home Interface

• Analogous to EJB home
• Supports factory and finder (for entity
  components) operations
• factory keyword denotes operation with creation
  semantics
• Supports user-defined operations
• Singleton object per component type/container,
  provides rough equivalent to class methods or
  static methods

18
Whats new in Packaging

• Generalized the component package descriptor into
  a new SOFTPKG descriptor
• separated container descriptor from SOFTPKG
  descriptor
• Added description of deployment process
• Improved level of specification

19
A Day in the Life of a Component

• A component is specified.
• A component is implemented.
• A component is packaged.
• A component may be assembled with other
  components (usually in a design tool).
• Components and assemblies are deployed.

20
Roles
21
Component Packaging

• A CORBA component is, among other things, a unit
  of deployment.
• That basic unit of deployment is realized as a
  component archive file.

22
Packaging

• A package consists of an XML descriptor and a set
  of files.
• The descriptor and files may be packaged together
  in a ZIP file or separated.
• If separated, the descriptor has references
  pointing to the other files.
• 2 types of packages software package and
  assembly package.

23
Component Packaging

• A component is represented by a software package.
• The SOFTPKG descriptor of the component software
  package describes
• one or more implementations of the component
• pointers to a container descriptor for each
  implementation and property files
• general information about the component

24
Component Assembly

• A component assembly is a pattern or a template
  for a deployed set of interconnected components.
• Described by a assembly descriptor in terms of
  component files, partitioning, and connections.
• May be deployed as is or imported into a design
  tool and reused or extended.

25
Deployment

• A component assembly is deployed by a deployment
  tool.
• The deployment tool interacts with the user to
  assign individual and collocated components to
  actual hosts.
• The deployment application interacts with
  installation objects on each machine.

26
Deployment
27
Whats Changed in the Container

• Split into three chapters
• the server programmers view of the container
• the container providers view of the ORB
• integration with the PSS provider (placeholder)
• Completed event APIs
• Reworked the session container
• Improved level of specification

28
Key Tenets

• A Container is a specialized POA
• Implemented by a Component-Aware ORB
• Provides Framework for Server Applications
• Provides External interfaces to clients
  (factories and method invocation)
• Provides Locality-constrained interfaces
  (valuetypes) for Systems Services (transactions,
  security, events, persistence)
• Provides Callbacks for instance management
  (activation and passivation)

29
Client View

• Component-aware and Component-unaware clients
• Three categories of components seen as two design
  patterns
• Factory - Client finds factory to create new
  instance
• Lookup - Client uses naming (or trader) to find
  existing component instance
• Optional demarcation of transactions
• Establishes initial security credentials
• Invokes application methods

30
Server View

• Three types of components
• Session (like EJB stateless Session Bean)
• Process (server side application persistence)
• Entity (like EJB Entity Bean with PSS-based
  automatic persistence)
• Container APIs for system services
• Callback APIs for instance management

31
Container Services

• Reference creation
• Instance creation
• Transactions
• Security
• Events
• Persistence
• Servant lifetime management

32
Component Factories

• Default factories can be code generated by tools
• Custom factories signatures defined by factory
  IDL declaration
• Factories create both references and instances
• Instance creation can use POA activation for
  process components

33
Transactions

• Flat transactions only
• Demarcation can be controlled by component
  descriptor and/or component instance at run time
• Container supports accessor to current
  transaction
• Transaction API mapped to CORBA transactions

34
Security

• Container supports accessor for security current
• Most security declared in deployment descriptors
• Component can access and test credentials at run
  time
• Security API mapped to CORBA security

35
Events

• Function is subset of CORBA notification
• Push Model
• Structured Events
• Container manages channel creation
• Quality of service properties declared in
  deployment descriptors
• Event API mapped to CORBA notification

36
Persistence

• Two methods defined
• automatic for Entity components - implemented by
  container and a PSS provider
• component managed for Process components -
  implemented by component implementation
• Entity components are dependent on a solution for
  PSS integration
• Process component can use any persistence
  mechanism (including PSS)

37
Container Provider View

• Three categories of containers defined with their
  specialized POAs and Servant Managers
• Session - transient references and instance
  pooling
• Process - persistent references and dedicated
  servants
• Entity - persistent references and dedicated
  servants

38
What Else is New in Submission?

• MOF-based meta-model (chapter 9)
• EJB mapping with interoperability (chapter 10)
• Conformance Points (chapter 13)
• Extensions to CORBA core
• May be other compliance points
• COM/MTS overview (appendix C)
• Module naming scheme for CORBA 3.0 (appendix A)

39
What needs to be done (major)

• Integration with a persistence solution
• Application view (chapter 4)
• Container providers view (chapter 7)
• Complete EJB alignment
• EJB 1.0 or EJB 1.1?
• Sun is now participating

40
What needs to be done (minor)

• Interface Repository extensions
• Complete Deployment specification
• New Language Mappings
• Updated Meta-model
• Improved level of specification throughout

41
Motions

• CORBA Components is a critical piece of CORBA 3.0
  and needs to be completed
• Work to be done requires a revised specification
  but
• will not change the fundamental model and
• will be mostly new text describing the
  persistence solution
• Move revised submission date to March 1
• Submit letter requesting a vote in Philadelphia