Making Sense of CORBA Components

1
Making Sense ofCORBA Components

• Frank Pilhofer
• OMG Meeting Paris, April 2001

2
CCM Goals

• Be like Java Beans
• Components express their connections to other
  components
• Assembling Components
• Handling with graphical tools
• Be like Enterprise Java Beans
• Container Programming ModelNon-functional
  aspects are handled automatically
• Navigation, Introspection, Persistency,
  Transactions, Security etc. managed by generated
  code
• Keep these two independent ideas separate!

3
The Component Model

• IDL 3 is translated to IDL 2 (optional / internal
  step)
• Equivalent IDL is then used to generate stubs and
  skeletons
• Stubs are for use by the client
• Skeletons are implemented by the Container or
  Container-generated code
• Invocations of business methods are delegated to
  the user-provided executor
• IDL and equivalent IDL seems okay so far

4
Minor Issues

• Be consistent in the usage of structs vs.
  valuetypes
• Equivalent IDL for receptacles uses struct
• ComponentsReceptacles uses valuetype
• Be consistent about introspection features
• ComponentsNavigation allows introspection of
  all facets
• ComponentsReceptacles does not
• ComponentsEvents neither

5
What is a Facet?

• The concept of facet seems to be the reverse of a
  receptacle, i.e. an object reference exported
  from the component
• Scenario Component phones home to retrieve an
  object reference for some service
• Makes a good candidate for a facet
• Currently disallowed (by CIDL and CIF), facets
  are handled as an internal implementation detail
  only
• According CIDL/CIF, there is no difference
  between facets and supported interfaces but for
  separate activation as a segmented executor
• Is separate activation really necessary anyway?

6
Do we need CIDL?

• The parts of CIDL are
• PSDL for defining a components persistent state
• Not necessary for service or session components
• Names of component and home executors
• Useless in C anyway, user-provided classes
  (executor instances) can only be constructed from
  user code
• Definition of executor segments
• Are these really necessary?
• Do without CIDL for non-persistent components,
  see if PSDL is (can be made) sufficient for
  persistent ones

7
Language Mapping

• It is necessary to agree on a Language Mapping
• How facets, receptacles and events are exchanged
  between container and user code
• What code is generated and what is to be
  user-provided
• How homes and components relate to each other
  wrt
• Construction of executor instances
• Who does factory-ing and finding (user code /
  glue code)
• Observe C-specific problems compared to Java
• Try to achieve largely Container-unspecific
  Language Mappings for components and homes
• Hide container-specific issues in SessionContext
  et al

8
C Difficulties

• Generated glue code cannot construct user class
  instances (here executors)
• Fully generated homes as in EJB are impossible
• User provided Entry Points are awkward but may
  be impossible to avoid?
• A class cannot optionally implement an
  interface, glue code needs advance knowledge of
  inheritance
• User must link in code for all components
  declared in an IDL file, or the result wont link
  or load
• Common practice of monolithic IDL files will
  fail
• Whats the role of C RTF in this?

9
Prototypical Implementation in MICO
interface Hello void sayHello () component
HelloWorld supports Hello attribute string
message home HelloHome manages HelloWorld

• Code generator reads IDL and produces

local interface CCM_
, ComponentsSessionCom
ponent operations
10
Prototypical Implementation in MICO
class HelloWorld_impl virtual public
CCM_HelloWorld private CORBAString_var
_msg public void sayHello () cout CORBAstring_dup (_msg) void message (const
char msg) _msg msg class
HelloHome_impl virtual public CCM_HelloHome
public CCM_HelloWorld create () return
new HelloWorld_impl CCM_HelloHome
create_HelloHome () return new
HelloHome_impl
11
More Prototypical Language Mapping Rules

• IDL feature
• provides
• uses
• uses multiple
• emits, publishes, consumes
• factory ()
• finder ()

• C equivalent operation
• _get_facet_ ()
• void _set_recep_ (in )
• void _set_recep_ (in Connections)
• (not yet implemented)
• CCM_ ()
• CCM_ ()

12
Suggestions for the FTF

• Keep
• Component Model
• Container Programming Model
• Scratch and restart thinking about
• CIDL
• CCM Implementation Framework
• More work needed on verifying and explaining
• Configuration process (who does what and when?)
• Software Package Descriptors?
• Component Descriptors?
• Component Assembly Descriptors?
• Property File Descriptors?

13
More Suggestions

• At the moment, CCM is too complex and comes with
  too much new terminology
• Adhere to the Kiss Principle Keep It Simple,
  Stupid!
• Make as many steps as possible optional
• thinking of persistence
• writing component, assembly, descriptors
• Keeping key concepts separate makes fixing or
  changing them lateron easier
• Pass new specifications progressively

14
Quality of Service

• The main objective of the Container Programming
  Model is to automate handling of non-functional
  aspects
• So far, we are thinking about persistence and
  transactions, but theres also
• Security
• Quality of Service
• etc.
• Each aspect needs their own CIDL equivalent
• Carefully design the CPM fundament to not exclude
  these possibilities!