CORBA Components

1
CORBA Components

• Edward Cobb, BEA Systems, Inc.
• Dave Frankel, Genesis Development
• Dave Curtis, Inprise Corp.
• Patrick Thompson, Rogue Wave
• March 23, 1999
• orbos/99-03-22

2
Abstract Component Model
3
Abstract Model

• Describes client view of component surface
  features
• Extensions to IDL
• map to equivalent pre-component (retro) IDL

4
Component

• component is a new CORBA meta-type
• extension of Object (with some constraints)
• has an interface, and an object reference
• also, a stylized use of CORBA interfaces/objects
• in (yet incomplete) interface repository
  extensions, ComponentDef derives from InterfaceDef

5
Equivalent IDL

• module example
• component C
• features

• module example
• interface C
• ComponentsComponentBase
• equivalent features

6
Component Features

• Facets
• Receptacles
• Attributes
• Event sources
• publisher
• emitter
• Event sinks

7
Abstract Model
receptacles
component facet
facets
event sink
attributes
event source
8
Facets

• Interfaces that provide the components
  application functionality to clients
• Each facet embodies a view of the component,
  corresponds to a role in which a client may act
  relative to the component
• A facet represents the component itself, not a
  separate thing contained by the component

9
Navigation

• From any facet to component facet with
  CORBAObjectget_component()
• returns nil if target isnt a component facet
• returns component reference otherwise
• From component reference to any facet
• via generated facet-specific operations
• via generic navigation operations on ComponentBase

10
Receptacles

• Describe possible connectivity, ability to
  specialize by delegation, compose functions
• the bottom of the Lego, if you will
• No inherent life cycle dependencies or ownership
  relationship implied
• no operations are inherently transitive across
  receptacle connection
• Not intended as a relationship service

11
Events

• Simple event model
• Events are all value types derived from
  ComponentsEventBase (empty, abstract)
• Push model
• Container mediates access to CosNotification
  channels
• scalability, quality of service, transactional,
  etc.

12
Event Sources

• Two types publisher and emitter
• Publisher is intended for 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 push consumer proxy
• intended for connection to an arbitrary event
  channel during configuration

13
Publisher
Container
Component
14
Publisher
notification channel
Container
Component
15
Publisher
notification channel
Client event consumer
Container
Component
16
Emitter
notification channel
Container
Client event consumer
Component
17
Attributes

• Intended use is for configuration
• existing successful re-use strategies rely
  heavily on configuration (e.g., optional
  behaviors, modality, resource hints, etc.) via
  properties or attributes
• can be supported by visual property sheet
  mechanisms in assembly or deployment environments
• cover details later in discussion of homes

18
Homes

• The term home is used to refer to
• a type (a home interface type)
• a specific home instance
• A home is an object that manages a set of similar
  components
• life cycle management
• maps key values to entity components
• extensible with arbitrary user-defined operations

19
Homes

• A home manages a specified component type
• home definition is distinct from component
• more than one home type can manage the same
  component type (not true of instances!)
• allows life cycle characteristics or key type to
  vary/evolve without changing component definition

20
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
• must be a value type derived from
  ComponentsPrimaryKeyBase (empty, abstract)
• can be used to find, destroy

21
Primary Keys

• Association between a primary key and a component
  is defined and maintained by a home
• primary key is not necessarily a part of the
  components state
• different home types may define different key
  types (or no key) for the same component type

22
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 for a client, based on the clients
  request and any available environmental or
  configuration data
• A home finder constitutes a domain of
  home/container/implementation visibility

23
Configuration and Homes

• As described earlier, attributes are intended for
  component configuration
• set during initialization, possibly readonly
  thereafter
• determine behavior (within range of possible
  behaviors)
• vital for re-usability

24
Container Model
25
Inputs CORBA Components
26
The Container Model

• A Framework for Server Applications
• Built on the Portable Object Adaptor
• Provides interfaces for CORBA Services
• transactions
• security
• events
• persistence
• Uses Callbacks for instance management
• Empty container for user-defined frameworks

27
Defined Container Frameworks
28
Container Implementation Types

• Stateless
• Multiple ID policy
• TRANSIENT references
• Conversational
• Unique ID policy
• TRANSIENT references
• Durable
• Unique ID policy
• PERSISTENT references

29
Container Types

• Transient
• Container managed references
• Stateless or transient state
• No persistence support
• Persistent
• User managed references with PSS
• Persistent state which may be transactional
• Container or component-managed persistence

30
External Types

• No Key Visibility
• primary key not exposed to client
• factory design pattern
• business processes (e.g., taking out a loan)
• Key Visibility
• primary key exposed to client
• factory or finder design pattern
• business entities (e.g. customer, account)

31
Component Categories
32
Container Managed Policies

• Servant Lifetime
• Transaction
• Security
• Events
• Persistence

33
Servant Lifetime Policies

• method - valid for all categories
• activated on first operation invocation and
  passivated on completion
• transaction - valid for all but service
• activated on first operation invocation and
  passivated at transaction completion
• component - valid for all but service
• activated on first operation invocation,
  destroyed explicitly
• container - valid for all but service
• activated on first operation invocation and
  deactivated when container needs to reclaim memory

34
Transactions

• Flat transactions only
• Demarcation can be controlled by component
  descriptor and/or component instance at run time
• Transaction API mapped to CORBA transactions
• Supported Policies
• NOT_SUPPORTED
• REQUIRED
• SUPPORTS
• REQUIRES_NEW
• MANDATORY
• NEVER

35
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
• Security Policies
• CLIENT_IDENTITY
• SYSTEM_IDENTITY
• SPECIFIED_IDENTITYuserid

36
Events

• Function is subset of CORBA notification
• Events represented as valuetypes to components
• Push Model
• Container maps valuetypes to Structured Events
• Container manages channel creation
• Quality of service properties left to
  configuration
• Event API mapped to CORBA notification
• Event Policies
• non-transactional
• default
• transactional

37
Persistence

• Supported for Persistent container types only
• Container supports two modes
• component managed
• container managed
• Either mode can use PSS or its own persistence
  mechanism
• Persistence Policies
• component managed
• container managed

38
Client View

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

39
Packaging
40
Component Development

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

41
The Big Picture
42
Component Packaging

• A CORBA component is, among other things, a unit
  of deployment.
• A packaged component may be deployed alone or in
  conjunction with other components in a component
  assembly.

43
Archive Files

• Two types of archive files are specified, one for
  components and the other for assemblies.
• These archive files are ZIP format files.

44
Descriptors

• Four types of descriptors are specified softpkg,
  corbacomponent, componentassembly, and
  properties.
• Each of these descriptors are specified using an
  XML vocabulary.

45
Component Package

• A component package is a ZIP archive file.
• It contains a softpkg descriptor, a CORBA
  component descriptor, implementation files, IDL
  files, and property files.
• Multiple implementations may be included in the
  archive (e.g. for different platforms).

46
Component Packaging Artifacts
47
softpkg descriptor

• The softpkg descriptor is used to describe
  general software packages.
• A descriptor element points to CORBA component
  specific information.

48
Major softpkg elements

• 
  
  

49
softpkg implementation Element

• 
  
  
  

50
Component Descriptor

• The component descriptor is referenced in the
  softpkgs descriptor element (a child element of
  implementation).
• The initial component descriptor is generated by
  the CIDL compiler.
• It describes information about the component that
  is needed for component assembly and deployment.

51
corbacomponent descriptor

• 
  policy
  ...
  ...

52

• 
  
  usepsstrue
  

53
Component Assembly

• A component assembly is a pattern or a template
  for a deployed set of interconnected components.
• Described by a component descriptor in terms of
  component files, partitioning, and connections.
• May be deployed as is or used in another
  assembly.

54
Component Assembly Artifacts
55
Assembly Package

• Like a component package, an assembly package is
  a ZIP archive file.
• It contains a component assembly descriptor,
  component archive files, and property files.

56
Assembly Descriptor

• The assembly descriptor describes an initial
  deployable configuration of homes, components,
  and connections.

57

58

59

• 
  ecutableplacement
  tion cardinality
  

60

• 
  
  
• 
  e name/ ctinterface

61
Property Files

• A general property description is specified.
• Used to set home and component properties.
  (However, it could be used for anything.)
• Component properties can be applied to individual
  components or to a home which will apply the
  properties to all components created through that
  home.
• Homes may have their own properties.

62
Property Files
63

• typelong/ 256
  256
  typepoint typelong 100
  
  300

64
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 and processes.
• The deployment application interacts with
  installation objects on each machine.

65
Deployment Participants
66
CCM Metamodels
67
MOF Background

• Standard Passed by OMG, 1997
• Standard Constructs for Describing metamodels
• Premise There will be more than one metamodel
• Supplemented by XMI Specification, 1998

68
Scenario An Integrated Repository
MOF-Compliant Repository
UML Models
CCM CORBA Interface Repository
Other Kinds of Metadata
Data Models
Workflow Models
CCM Packaging/Deployment Descriptors
Generic MOF Tools
69
Scenario A Federated Repository
70
Mapping the MOF Core to IDL
MOF Core
CORBA IDL
71
The MOF-XML Mapping
Yields XML DTDs for MOF-Compliant Metamodels
MOF Core
XML Document Type Definition (DTD)
72
Three MOF-Compliant Metamodels Each Having IDL
and XMI DTD
Interface Repository (MOF-Compliant)
XML Stream Based On IR XMI DTD
IDL
Import-Export
UML Model Repository
UML Model Repository
XML Stream Based On UML XMI DTD
IDL
Import-Export
UML Model Repository
P/D Descriptor Repository
XML Stream Based On P/D XMI DTD
IDL
Import-Export
73
CORBA IR Metamodel Packages
74
ComponentIDL Main
75
Formal Expression of Constraints!
76
Comparison of MOF-Based IR BaseIDL Package With
Non-MOF IR

• Very close structurally
• Opportunity was taken to do a bit of streamlining
• e.g. base metaclass Typed prevents repetition of
  the type attribute in six different IR
  metaclasses
• No parallel structs
• DII will continue to be based on non-MOF CORBA IR
  for foreseeable future
• Upcoming versions of MOF will support
  single-operation to export a ComponentDef and its
  transitive closure via XMI
• No Repository metaclass
• MOF Facility interfaces provide this
  functionality
• Basic CRUD operations omitted
• Generated by MOF-IDL mapping
• Reflective interfaces provide generic CRUD

77
Wrapping the Non-MOF IR With the MOF-Based IR
Interfaces
78
Packaging/Deployment Metamodel
79
Compliance

• These are the normative OMG MOF-Based DTDs and
  IDL for the CORBA IR and Packaging/Deployment
  Descriptors
• Optional for CCM implementations to implement them

80
Known Issues

• Packaging/Deployment metamodel
• Not in sync with latest revision of P/D chapter
• DTD size is excessive
• Packaging/Deployment IDL not yet in spec
• IR metamodel
• ComponentDef can now support 0.. InterfaceDef
• ProvidesDef-FacetDef, UsesDef-ReceptacleDef
• Naming relationship reference interface causes
  problems for IDL generator replaced with
  uml_interface, which is odd

81
Fragment of IR XMI DTD
supports (BaseIDL.InterfaceDef
ComponentIDL.ComponentDef ComponentIDL.HomeDef
)? ons '(BaseIDL.InterfaceDefAssociations
,ComponentIDL.ComponentDef.supports?)'
'(BaseIDL.InterfaceDefCompositions)'
((XMI.extension , ComponentIDL.ComponentDefAss
ociations ) , ComponentIDL.ComponentDefC
ompositions )? Def XMI.element.att XMI.link.att
82
Fragment of IR MOF-Compliant IDL
include Reflective.idl module Base IDL
module ComponentIDL interface
ComponentDefClass BaseIDLInterfaceDefClass
readonly attribute ComponentDefUList
all_of_kind_component_def readonly
attribute ComponentDefUList all_of_type_component_
def ComponentDef create_component_def ()
raises ( ReflectiveSemanticEr
ror, ReflectiveConstraintError)
interface ComponentDef ComponentDefClass,Ba
seIDLInterfaceDef BaseIDLInterfaceD
ef supports () raises (
ReflectiveNotSet,
ReflectiveSemanticError) void
set_supports (in BaseIDLInterfaceDef
new_value) raises (ReflectiveSemanticEr
ror) void unset_supports ()
raises (ReflectiveSemanticError)
83
EJB and CORBA Components
84
CORBA Components and EJB
85
A CORBA EJB Container

• A precise mapping of the EJB container to CORBA
  infrastructure
• Use of CORBA services for EJB APIs
• Results
• Interoperability
• Better EJB portability

EJB
EJB
CORBA-EJB Container
CORBA-EJB Container
ORB/POA
PSS
86
Server Adaptation Strategies

• EJB as a new container type
• native EJB APIs map directly to CORBA
  infrastructure
• only EJB client programming model
• EJB mapped to CCM container type
• Session beans to Transient Container Type
• Entity beans to Persistent Container Type
• Supports CCM client programming model

87
EJB Client to CCM Server

• CCM component which
• supports a single interface
• uses Java data types
• EJB client programming model
• EJBHome façade of Home
• EJBObject façade of supported interface

EJB
CCM
CORBA-EJB Container
CCM Container
ORB/POA
PSS
88
CCM Client to EJB Server

• CCM Client Model
• single supported interface
• No advanced functions
• EJB Server Model
• Java data type
• EJBHome and EJBObject
• Requires
• Java to IDL mapping for client
• Issue - mapping to component IDL

CCM
EJB
CCM Container
CORBA-EJB Container
ORB/POA
PSS
89
CCM and EJBIrreconcilable Differences

• Design Starting Point
• CORBA - IDL
• Java - Java programming language
• Overlapping but non-identical type systems
• CORBA - IDL data types
• Java - basic IDL data types plus values,
  inheritance on exceptions
• Naming Rules
• case sensitivity
• overloading

90
Whats Next

• Errata document (orbos/99-02-09) available
• New container implementation framework
• Updated packaging specification
• Whats missing and to be revised
• Introduction to Components
• Interface Repository Extensions
• Deployment
• general chapter updates