1. UNCLASSIFIED
CARDAMOM
61 486 532 AA
CTD
300-2
Date 02/02/2004
E295-06-00012TRL Rev 01
UNCLASSIFIED Page 1 of 192
CCM TUTORIAL
For
CARDAMOM VX.X
CARDAMOM
TUTORIAL VX.0
DRAFT
CONTRACT N° 02-067
Prepared by :
THALES
45, rue de Villiers
92526 Neuilly-Sur-Seine CEDEX
France
AMS
Via Tiburtina, Km 12.400
00131 ROMA
ITALY
2. UNCLASSIFIED
CARDAMOM
61 486 532 AA
CTD
300-2
Date 02/02/2004
E295-06-00012TRL Rev 01
UNCLASSIFIED Page 2 of 192
CARDAMOM
DOCUMENT TITLE:
CCM TUTORIAL
DOCUMENT CONTENT & PURPOSE:
The purpose of this document is to help CARDAMOM newcomers learn how to use the
product effectively
INTERNAL APPROVALS
REVISION: 01 Signature Date
WRITTEN BY:
E. FUCHS 02/02/2004
EXTERNAL APPROVALS
3. UNCLASSIFIED
CARDAMOM
61 486 532 AA
CTD
300-2
Date 02/02/2004
E295-06-00012TRL Rev 01
UNCLASSIFIED Page 3 of 192
CHANGES
Rev. Date Description
Person in
Charge of
Change Request
Reference
01 02/02/2004 First version E.FUCHS
4. UNCLASSIFIED
CARDAMOM
61 486 532 AA
CTD
300-2
Date 02/02/2004
E295-06-00012TRL Rev 01
UNCLASSIFIED Page 4 of 192
LIST OF ABBREVIATIONS
Refer to CARDAMOM Glossary document (ref [4]).
15. UNCLASSIFIED
CARDAMOM
61 486 532 AA
CTD
300-2
Date 02/02/2004
E295-06-00012TRL Rev 01
UNCLASSIFIED Page 15 of 192
Figure 15-5 component <programs> element .......................................................................................................166
Figure 15-6 component home entry pointt.............................................................................................................167
Figure 16-1: Component-IDL mapping..................................................................................................................169
Figure 16-2: CCM110 cad. ....................................................................................................................................170
Figure 16-3: CCM110 cad 2 ..................................................................................................................................171
Figure 16-4: receptacle to naming object ..............................................................................................................173
Figure 16-5: CCM140 cad .....................................................................................................................................175
Figure 16-6: Server Component supported Interface scenario .............................................................................177
Figure 16-7 : Server Component supported Interface...........................................................................................178
Figure 16-8: supported interface IDL mapping......................................................................................................178
Figure 16-9: Support interface local IDL................................................................................................................179
Figure 17-1 Hello IDL.............................................................................................................................................183
16. UNCLASSIFIED
CARDAMOM
61 486 532 AA
CTD
300-2
Date 02/02/2004
E295-06-00012TRL Rev 01
UNCLASSIFIED Page 16 of 192
LIST OF TABLES
Table 1 : list of CCM examples................................................................................................................................27
Table 3-1 Example directory contents.....................................................................................................................32
Table 3-2 Example directory generated ..................................................................................................................32
Table 3-3 CCM package manager directory............................................................................................................32
17. UNCLASSIFIED
CARDAMOM
61 486 532 AA
CTD
300-2
Date 02/02/2004
E295-06-00012TRL Rev 01
UNCLASSIFIED Page 17 of 192
Table of Base Connection-IDL
Base Connection-IDL 1: CCM Object......................................................................................................................67
Base Connection-IDL 2: CCM Home.......................................................................................................................70
18. UNCLASSIFIED
CARDAMOM
61 486 532 AA
CTD
300-2
Date 02/02/2004
E295-06-00012TRL Rev 01
UNCLASSIFIED Page 18 of 192
Table of base local IDL
CCM local IDL Base 10-1: enterprise component ...................................................................................................89
CCM local IDL Base 10-2: executor locator ............................................................................................................90
CCM local IDL Base 10-3: session context .............................................................................................................92
CCM local IDL Base 10-4: session component.......................................................................................................94
19. UNCLASSIFIED
CARDAMOM
61 486 532 AA
CTD
300-2
Date 02/02/2004
E295-06-00012TRL Rev 01
UNCLASSIFIED Page 19 of 192
Table of XML elements
XML elements 12-1: Software package main elements.......................................................................................122
XML elements 12-2: Software package descriptor example................................................................................123
XML elements 12-3: CORBA Component descriptor XML element.....................................................................124
XML elements 12-4: ClientHome CCD.................................................................................................................125
XML elements 12-5: CCM80 server component property file ..............................................................................126
XML elements 12-6: simple XML element definition ............................................................................................127
XML elements 12-7: CCM80 server instance 1 component property file.............................................................127
XML elements 13-1: Componentassembly main elements ..................................................................................131
XML elements 13-2: Component file elements ....................................................................................................132
XML elements 13-3: Component file elements example......................................................................................133
XML elements 13-4: Partitioning elements...........................................................................................................134
XML elements 13-5: Location and instantiation elements example .....................................................................135
XML elements 13-6: connection elements ...........................................................................................................136
XML elements 13-7: connection elements connectinterface................................................................................137
XML elements 13-8: Connection elements example...........................................................................................138
XML elements 13-9: connection elements connectevent.....................................................................................139
XML elements 13-10: CCM050 Connection event publisher elements................................................................140
XML elements 13-11: CCM060 Connection event source elements ...................................................................141
XML elements 13-12: registerwithnaming elements example..............................................................................142
XML elements 13-13: Connection existing interface elements example..............................................................143
XML elements 13-14: CCM080 homeplacement .................................................................................................144
XML elements 13-15: CCM140 homeplacement .................................................................................................145
XML elements 14-1: Connexion elements example.............................................................................................153
XML elements 16-1: supported interface CAD.....................................................................................................180
20. UNCLASSIFIED
CARDAMOM
61 486 532 AA
CTD
300-2
Date 02/02/2004
E295-06-00012TRL Rev 01
UNCLASSIFIED Page 20 of 192
Table of Class Diagram
Class Diagram 10-1: Component local interface mapping......................................................................................88
Class Diagram 10-2: Main executor server example ..............................................................................................90
Class Diagram 10-3: container session component association.............................................................................90
Class Diagram 10-4: Monolithic executor................................................................................................................91
Class Diagram 10-5: container session component association.............................................................................92
Class Diagram 10-6: container session component association.............................................................................92
Class Diagram 10-7: container session component association.............................................................................93
Class Diagram 10-8: container session narrowing class diagram ..........................................................................93
Class Diagram 10-9: Session Component ..............................................................................................................94
Class Diagram 10-10: Session Component and container .....................................................................................95
Class Diagram 10-11: Session Component and container .....................................................................................95
Class Diagram 10-12: Home local interface mapping .............................................................................................97
Class Diagram 10-13: CORBA object local IDL mapping example.........................................................................98
Class Diagram 10-14: Facet monolithic executor operation....................................................................................99
Class Diagram 10-15: receptacle context operation .............................................................................................101
Class Diagram 10-16: Sink monolithic executor operation....................................................................................102
Class Diagram 10-17: container session component association.........................................................................104
Class Diagram 10-18: Attribute local interface ......................................................................................................105
Class Diagram 10-19: Attribute local interface ......................................................................................................105
Class Diagram 10-20: Local IDL full lattice class diagram ....................................................................................107
Class Diagram 14-1 : Component Installation.......................................................................................................154
Class Diagram 14-2: Assembly Factory ................................................................................................................155
Class Diagram 14-3 : Assembly ............................................................................................................................156
Class Diagram 14-4 : server activator ...................................................................................................................156
Class Diagram 14-5 : Component Server..............................................................................................................157
Class Diagram 14-6 : Container ............................................................................................................................158
21. UNCLASSIFIED
CARDAMOM
61 486 532 AA
CTD
300-2
Date 02/02/2004
E295-06-00012TRL Rev 01
UNCLASSIFIED Page 21 of 192
1. SCOPE
1.1 IDENTIFICATION
Document Name :CCM TUTORIAL.
Document Short Name : TRL.
CSCI Short Name : TRL
CDRL Number : NA.
Thales Number : 61 486 532 AA
AMS Number : E295-06-00012TRL
CTD : 300-2
Revision : 01
Revision Date : 02/02/2004
File Name : CARDAMOM_CCM_Tutorial_Draft 2004
This Document is applicable to the TUTORIAL VX.0 corresponding to the CARDAMOM VX. product.
1.2 PRODUCT OVERVIEW
CARDAMOM is a middleware platform enabling component based software architecture for the implementation
of safety and mission critical systems, such as those for air traffic control and command management systems.
CARDAMOM provides a framework for the integration of both Business Components of the functional
architecture and Technical Components of non-functional architecture.
Components are either proprietary components or COTS (Commercial Off The Shelf) components.
To provide a standard Plug and Play of a large set of components, CARDAMOM is based on the main
interoperability standards, defined by the Object Management Group (OMG) organisation:
At business level CARDAMOM uses UML and XML OMG standards,
As separation layer CARDAMOM uses CCM OMG standard in order to isolate the business logic from
the technical services,
At technical level CARDAMOM uses CORBA OMG standard.
For a more complete overview of CARDAMOM refer to the Product Overview Document (ref. [5]).
22. UNCLASSIFIED
CARDAMOM
61 486 532 AA
CTD
300-2
Date 02/02/2004
E295-06-00012TRL Rev 01
UNCLASSIFIED Page 22 of 192
1.3 DOCUMENT OVERVIEW
This document is the tutorial for the CARDAMOM CORBA Component Model (CCM) implementation. The CCM
is intended to enable assembling applications from pre-built, off-the-shelf component implementations.
This paragraph presents an overview of the different chapter of this document.
Chapter 2 REFERENCED DOCUMENTS lists documents that are referenced across this document.
Chapter 3 CCM CARDAMOM USAGE EXAMPLE DIRECTORY TREE
This chapter presents the CARDAMOM tutorial file organization. We present each directory and its content. This
directory organization has been chosen for the CARDAMOM tutorial, you can define your own organization.
Chapter 4 USAGE EXAMPLES INSTALLATION
This chapter describes the modus operandi to install the CARDAMOM tutorial.
Chapter 5 SOFTWARE COMPONENT OVERVIEW
This chapter gives a brief overview of software component in broad. It presents the foundation concepts of
software components through the academic definition. We expose here the fundamental characteristic of a
component model. This is a general introduction to component model, actual component model being CCM.
The main concepts of this introduction are the component contractual interface and component contextual
dependency. Contextual dependencies descriptions enable plug and play of component instances to build a
distributed application by reusing exiting software product. Contextual dependencies address both
dependencies vis-à-vis other components and dependencies vis-à-vis the execution platform.
Chapter 6 CORBA COMPONENT MODEL
The CCM is the CORBA standard specification for software component development.
In this chapter we present the main aspects provided by CCM: abstract component model, configuration model,
deployment model and server side component instance software architecture.
CCM enables to describe:
Component contextual dependencies vis-à-vis other components and provides CORBA object
definition to manage component creation and connection.
Component execution environment dependencies
CCM brings the concept of component configuration instance used to customize component.
In CCM component contractual interface are CORBA object interface. It is why we can say that CCM provides
a standard way to deploy CORBA objects.
23. UNCLASSIFIED
CARDAMOM
61 486 532 AA
CTD
300-2
Date 02/02/2004
E295-06-00012TRL Rev 01
UNCLASSIFIED Page 23 of 192
Chapter 7 TUTORIAL RECURRENT EXAMPLE OUTLINE
In this chapter we introduce the recurrent examples used throughout this tutorial. We first have a single
component example (CCM010) to illustrate basic concepts. Then we develop two main examples, one for each
type of component interaction: synchronous (CCM020) and asynchronous (CCM050). At this step of the
document we only present an overview of each configuration. In the rest of the document we bring further
details as we progress in the presentation of CCM artifacts.
Chapter 8 COMPONENT-IDL TUTORIAL EXAMPLE
In this chapter we use the recurrent example to explain the component-IDL. We introduce here the new CORBA
IDL keywords. Component-IDL enables to describe component “features” made of ports and attributes. We use
recurrent examples to present each kind of ports and attribute.
CCM010 is used to present a single component without ports.
Then we introduce facet and receptacle ports for synchronous component interaction in CCM020.
CCM050 is used to introduce asynchronous ports event sink and event source.
Component attributes are presented in CCM080
In this chapter we address as well component factory: CCM Home and component-IDL based interfaces.
Chapter 9 CCM CONNECTION-IDL TUTORIAL EXEMPLES.
This chapter introduces through the recurrent examples the mapping from component-IDL to CORBA IDL. IDL
mapping rule defines a component object IDL containing specific operations to manage component instance
creation and connection. Component home operations are used to create component instance. Each
instance creation encompasses a set of CORBA object creation.
Component port Connections are merely a standard way to create CORBA object and to pass CORBA object
reference from server to client. We call this part of CCM IDL the connection-IDL. For each kind of connection-
IDL we introduce as well the connection-IDL base interfaces.
Chapter 10 CCM LOCAL IDL EXAMPLES
This chapter presents the definition of all local IDL interface. Local IDL defines the server side programming-
model. It is the container interface. Compare to CORBA object implementation CCM introduces new local
objects to manage component software reused and portability. For the sever role of the component CCM
provides a mechanism equivalent to CORBA servant: the component executor.
24. UNCLASSIFIED
CARDAMOM
61 486 532 AA
CTD
300-2
Date 02/02/2004
E295-06-00012TRL Rev 01
UNCLASSIFIED Page 24 of 192
On the client role of the component, CCM introduces a brand new concept to manage CORBA object reference
retrieval: the component context. As well CCM defines a new local object to manage the component instance
life cycle.
Chapter 11 LANGUAGE MAPPING and implementation through CCM tutorial example
CCM defines the server side programming-model for distributed component. It encompasses CORBA object
local implementation for the component server role and context object for client role to retrieve CORBA object
reference. It provides as well a callback interface for component instance life cycle.
Chapter 12 COMPONENT PACKAGING THROUGH TUTORIAL EXAMPLES
This chapter presents the component packaging process. Component packaging aims at providing a
component as a deployable unit. A single component CCM deployment unit is a CCM component package. As
well a CCM deployment unit may be a component assembly, in this case the deployment unit is a CCM
assembly. An assembly is a package of a component assembly. CCM defines a set of XML definition to
provide CORBA component explicit dependencies.
Component descriptor describes individual component implementation dependencies vis-à-vis the execution
platform. We first present the common packaging language element then we provide concrete usage pattern
with tutorial examples CORBA Component Descriptor (.ccd)..
Chapter 13 CCM ASSEMBLY TUTORIAL EXAMPLES
Assembly descriptor describes components instances web. It defines for each component the way to fulfil its
contextual dependencies vis-à-vis other software components in a given execution environment. In this
example we walk trough each description element of component assembly descriptor. For each kind of element
we provide an excerpt of tutorial example Component Assembly Descriptor file (.cad).
Chapter 14 CCM COMPONENT deployment
The CCM defines a component deployment model. This model encompasses a static model describing the
model object interface and a dynamic model presenting the deployment sequence. In this chapter we first
present the deployment sequence introducing each object of the deployment model. Then we present each
object of the deployment model. The last part of this chapter presents the CARDAMOM implementation of the
CCM deployment model. The deployment model is illustrated in a specific chapter by a “manual assembly
example”.
25. UNCLASSIFIED
CARDAMOM
61 486 532 AA
CTD
300-2
Date 02/02/2004
E295-06-00012TRL Rev 01
UNCLASSIFIED Page 25 of 192
Chapter 15 CARDAMOM CCM ENVIRONMENT THROUGH EXEMPLE: CCM110
This example uses the single component without ports or attributes. It is voluntary simple to let you concentrate
on the CARDAMOM CCM implementation specific aspects. This example forms as well a wrap up of various
concepts developed in the previous chapters.
In this chapter we address CARDAMOM technical services usage. Before reading this chapter it is mandatory
to read the CARDAMOM technical services tutorial (ref [7]). The CARDAMOM technical services used by the
CARDAMOM CCM implementation are: code generation, supervision, naming service and life cycle.
As well in this chapter, we will walk trough all the tutorial directory arborescence, form IDL to source
code.
Chapter 16 CONNECTION-IDL USAGE THROUGH TUTORIAL EXAMPLE
In this chapter we present the tutorial examples built for illustration of connection-IDL usage. The first aspect
addressed here is component disconnection and reconnection. The second one is component creation and
reconnection. The key issue is to acquire component object reference. In this series of example it is worth
analyzing “.cad” to see the possibilities offered by the CCM assembly object for managing component
instances dependencies.
CCM110 illustrates facet receptacle disconnection and reconnection between a client component and two
server components using IOR look up in CARDAMOM repository and naming service.
CCM120 runs the same scenario with the client component gaining access to CORBA naming service through
a dedicated receptacle.
CCM130 is equivalent to CCM110 for event sink and source.
Rather than using naming service, another way in CCM to get access to component object instance reference is
by requesting component creation to component home, which returns component object instance reference.
This pattern is illustrated in CCM140.
Chapter 17 CCM DEPLOYMENT THROUGH HANDCRAFTED ASSEMBLY : CCM310
This example is more complex it illustrates the CCM deployment through the code of a simplified CCM
assembly implementation.
26. UNCLASSIFIED
CARDAMOM
61 486 532 AA
CTD
300-2
Date 02/02/2004
E295-06-00012TRL Rev 01
UNCLASSIFIED Page 26 of 192
1.4 TUTORIAL PRINCIPLES
The purpose of this document is to help you to start with CARDAMOM CCM usage. In order to give you a
straightforward insight to the foundation concepts of CARDAMOM VX. CCM we try to apply the following rules:
Use simple toys examples to focus on CARDAMOM VX. CCM aspects rather than on a hypothetical
“ACME
1
” example.
Illustrate presentations with simple “use case”.
Code examples describe precisely the syntax and semantic of CARDAMOM VX. CCM usage. So
names are the simple as possible and reduced to “hello”. All source code examples refer to “Hello”
application object, so that you cannot mismatch example topics with CARDAMOM CCM concepts
and artefacts (ACME syndrome).
We insist on the fact: examples are not to be taken as design examples they are only toys examples targeted
to simplify your comprehension process. This document is yet not an architecture guide.
Before reading this document you have to read the CARDAMOM Software User Manual (SUM) [6] and the
CARDAMOM technical services tutorial [7].
You have to read this tutorial in front of a computer containing an installation of CARDAMOM CCM. While
reading, you will have to navigate in the tutorial directories. The tutorial directory structure in presented in
chapter 3.
The content of this the document has been based on the CCM training experience. We build explanations
contained in this document according to the training attendees questions and remarks.
1.5 EXAMPLES OVERVIEW
The next table gives the list of CARDAMOM CCM tutorial example with name and addressed topics.
1
ACME: is a common name used in cartoons, reused by computing people as foo, bar, booz,…
27. UNCLASSIFIED
CARDAMOM
61 486 532 AA
CTD
300-2
Date 02/02/2004
E295-06-00012TRL Rev 01
UNCLASSIFIED Page 27 of 192
Ccm010 (cf 9.2, 10.1) Basic component without facet and event.
Ccm020 (cf 9.3, 10.2) Facet and Receptacle with delegation executor relation.
Ccm030 (cf 9.3) Facet and Receptacle with inheritance executor relation.
Ccm040 (cf 16.6) Facet component supporting interface.
Ccm050 (cf 7.4, 8.3,
9.4, 10.3, 11.4, 13.3)
Event publisher (source port) and one consumer (sink port).
Ccm060 (cf 7.4, 8.3,
9.4, 13.4)
Event emitter (source port) and one consumer (sink port).
Ccm070 (cf 9.6, 11.5) Event with value type method
Ccm080 (cf 7.5, 8.4,
9.7, 10.4, 11.6, 12.6,
13.7)
Attributes for component configuration and properties (.cpf files)
Ccm110 (cf 9.3, 13.5,
15, 16.2)
Facet disconnection/connection (repository interface and naming service usage)
Ccm120 (cf 9.3, 13.6,
16.3)
Facet disconnection/connection (receptacle connection to naming service =>
CosNaming.idl include in Hello.idl file)
Ccm130 (cf 9.3, 16.4) Event connection (repository interface and naming service usage)
Ccm140 (cf 9.3, 13,
16.5)
Component creation and connection (naming service usage)
Ccm220 (cf 9.5) Event publisher with several consumers
Ccm230 (cf 11.7) Client calls server facet which sends event to client
Ccm310 (cf 14, 17) Manual assembly
Table 1 : list of CCM examples
We strive to progress incrementally into the difficulties, thus the first examples are very simple but introduce all
the basic concepts. The basic example is CCM010.
Then we increase this basic example by adding, as far as possible, one specific aspect at a time. As a matter
of fact we have 2 mains example:
Synchronous invocation: facet and receptacles: CCM020.
Asynchronous invocation: event sink and source: CCM050.
28. UNCLASSIFIED
CARDAMOM
61 486 532 AA
CTD
300-2
Date 02/02/2004
E295-06-00012TRL Rev 01
UNCLASSIFIED Page 28 of 192
The next example is CCM030 where we use inheritance instead of delegation as in CCM20 to integrate the
generated code with application code. CCM040 illustrates the basic component category features.
Next adding addresses the event CCM050 that used event publisher in one to one configuration. CCM060 is
the same with event emitter instead of event publisher. Next for event we have CCM220 which stages multiple
event consumers. A key concept for CCM event is event type. Event type is CORBA value type, CCM050
uses a value type equivalent to a structure, and in CCM070 we use a value type with a single hello world
method.
The next important case addresses component configuration using attributes and component attributes and
properties file (CCM080).
At the server code level we give an example of internal variable management for references exchange
between stubs and skeleton i.e. executor and context (CCM230).
The last kind of example address connection management during component life cycle:
Facet connection (CCM110).
Sink connection (CCM130).
In the CCM110 it is the component itself that manages its ports. The issue here being to get the component
object reference to request connection. The practical way to get reference its to create the component it is the
case of CCM140.
The last example CCM310 illustrates the CCM assembly object implementation.
1.6 MINIMUM READER BACKGROUND
To explain the concepts addressed in this document we make the assumption that you are familiar and
seasoned with the following subjects:
Object Oriented programming
C++
CORBA
Introduction to CCM
Introduction to component software technology
GOF
2
Design Pattern
XML
UNIX
As we cannot explain in this document all the concepts of those technologies, this background is mandatory.
2
GOF stand for Gang Of Four. It refers to the famous books of Vlisside and Co. Design Patterns: Elements of Reusable Object-Oriented
Software.
29. UNCLASSIFIED
CARDAMOM
61 486 532 AA
CTD
300-2
Date 02/02/2004
E295-06-00012TRL Rev 01
UNCLASSIFIED Page 29 of 192
2. REFERENCED DOCUMENTS
2.1 CONTRACTUAL DOCUMENTS
Name of the document Acronym Reference number
[1] CARDAMOM Collaboration Agreement N.A. Contract 02-067, 19/05/2003
[2] CARDAMOM Statement Of Work for a
THALES/AMS Common Software Platform
Project
SOW 26/05/2003
2.2 CDO - CARDAMOM DOCUMENTS
Name of the document Acronym Reference number
[3] CARDAMOM Product Item and Documentation
Index
PIDI
[4] CARDAMOM Glossary GLO
[5] CARDAMOM Product Overview PROV
[6] CARDAMOM Software User Manual SUM
[7] CARDAMOM technical services tutorial TRL
The exact issue of the documentation is given in the CARDAMOM PIDI (ref [3]).
30. UNCLASSIFIED
CARDAMOM
61 486 532 AA
CTD
300-2
Date 02/02/2004
E295-06-00012TRL Rev 01
UNCLASSIFIED Page 30 of 192
2.3 CSCI DOCUMENTS
At the application level, the CSCI documents do not need to be referenced
2.4 OTHER DOCUMENTS
Name of the document Acronym Reference number
[8] Objects, Components, And Frameworks with
UML, The Catalysis Approach. Desmond
Francis D’Souza.
N.A.
Publisher: Addison-Wesley Professional
ISBN: 0-201-31012-0
[9] Component Software, Beyond Object-Oriented
Programming. Clemens Szyperski.
N.A. Publisher: Addison-Wesley Professional
ISBN: 0-201-17888-5
[10] Large-Scale, Component-Based Development,
Alan W. Brown.
N.A. Publisher: Prentice-Hall
ISBN: 0-130-88720-X
31. UNCLASSIFIED
CARDAMOM
61 486 532 AA
CTD
300-2
Date 02/02/2004
E295-06-00012TRL Rev 01
UNCLASSIFIED Page 31 of 192
3. CCM CARDAMOM USAGE EXAMPLE DIRECTORY TREE
Each CCM example is contained within its own root directory.
It is important to have in mind the directory laid out when using CARDAMOM and analysing the examples.
Here is the content of the CCM010 example root directory. You will be able to see it on your development
environment after CARDAMOM installation as described in chapter 4 “CCM Usage Examples installation”.
Figure 3-1 CCM010 example root directory structures
Directories included in the example root directory are organised as in the CARDAMOM demo environment
directory as follows.
32. UNCLASSIFIED
CARDAMOM
61 486 532 AA
CTD
300-2
Date 02/02/2004
E295-06-00012TRL Rev 01
UNCLASSIFIED Page 32 of 192
Directory Name Contents
Data/ Contains tutorial programs XML data files.
idl/ Contains IDL files used by the provided example
include/ Contains header files used by the example.
run/ Contains scripts for starting tutorial programs
src/ Contains source files of the example
xml/
Contains 'user-provided' XML data files for CARDAMOM
code generation
Table 3-1 Example directory contents
You have to provide the recipient Files of this set of directories. You have to write files contained in those
directories.
However the files contained in the directories described in Table 3-2, are automatically generated. They are
created during the global makefile execution.
Directory
Name
Contents
generated/ Contains CARDAMOM generated files
host-type/ Build directory. Here i686-pc-linux-gnu
Table 3-2 Example directory generated
CARDAMOM CCM package manager creates another directory:
Directory
Name
Contents
workDir/ This directory is used for the deployment of the components.
Table 3-3 CCM package manager directory
33. UNCLASSIFIED
CARDAMOM
61 486 532 AA
CTD
300-2
Date 02/02/2004
E295-06-00012TRL Rev 01
UNCLASSIFIED Page 33 of 192
4. USAGE EXAMPLES INSTALLATION
All examples are located under a global directory named “tutorial”, and are provided in two versions: c++ and
Java. That is, the “tutorial” directory contains two subdirectories:
- tutorial /c++
- tutorial/java
Whatever the version you choose, the following rules are applied for each subdirectory:
4.1 CONFIGURATION
(1) For convenience, copy the “tutorial” directory under your home workspace
(2) Move to the directory “tutorial/c++”
(3) Launch the script “configure.sh”. This step will ask to enter the directory where is installed the
CARDAMOM distribution and will generate a file named “site.mk” that contains the appropriate
environmental variables needed to compile and execute examples.
4.2 COMPILING
Examples (named <ccm_suffix-number>) provided in the CARDAMOM TUTORIAL can be installed
independently or all together.
- To install examples independently, perform the following actions:
(1) Move to the example directory (“tutorial/c++/<example_name>”)
(2) Execute the make command to generate executables.
- To install all examples
(1) Under the directory “tutorial/c++” execute the command make. The provided Makefile checks the
value of the TUTORIAL_LIST given the list of examples to install. This value can be modified.
Although the Compiling step consists to generate the appropriate libraries and executable files according to used
programming language, in fact it performs some other tasks such files translation. Tasks performed by the
Compiling step are depicted hereafter.
4.2.1 FILES TRANSLATION
Rather than to impose a well-defined path, in which files used by the tutorial need to be installed, the approach
taken is to let the flexibility for the user to install the source files wherever he wishes. For this aim, the
configuration and descriptors files used by the demos are pre-defined with environmental variables that are
changed to the correct values that correspond to the path chosen by the used.
All files that concerned by such translation are mainly provided with extention “.in”. Such files are mainly located
under the directory “/xml” and “/data” for all examples and also under the directory “/run” for some
examples.The way to translate the variables defined in each type of file, for instance “xml.in”, is defined using
some rules located either in the file rules.mk, located under the directories “tutorial/c++” or
“tutorial/java” in the case of examples located under tutorial, or the file site.mk for examples provided
under the /demos directory of the Cardamom installation.
34. UNCLASSIFIED
CARDAMOM
61 486 532 AA
CTD
300-2
Date 02/02/2004
E295-06-00012TRL Rev 01
UNCLASSIFIED Page 34 of 192
The following lines illustrates how some variable are converted the “text.in” files, where for instance
@prefix@ is converted to the current directory and @cdmw_home@ is replaced by the value of the environmental
variable $(CDMW_HOME) defined in a file site.mk.
# Rules to build each TXT configuration file
%.txt: %.txt.in
@echo "Generating $@ from $<"
@echo s%@prefix@%$(PWD)%g >> sed_patterns
@echo s%@hostname@%`hostname`%g >> sed_patterns
@echo s%@cdmw_platform@%$(BUILD_TARGET)%g >> sed_patterns
@echo s%@cdmw_home@%$(CDMW_HOME)%g >> sed_patterns
@echo s%@FTP_DIR@%$(FTP_DIR)%g >> sed_patterns
4.2.2 MAKEFILES AND REQUIRED CARDAMOM LIBRARIES
The appropriate file translation and code generation and also the build of libraries and executable files, allowing
to run the examples, are based is based on the following files.
- A Makefile located in the root of each example, in which we define the files that need to be translated
or submitted for code generation, and also the directory that contain the files to compile.
- A Makefile located under the directory “/src” or each example in which the location of configuration
file needed to compiling are defined to be involved in the processing, and the file that contains the files to
compile (Main.mk)
- A Main.mk (only for c++) located under the directory “/src” or each example (in which the files that
need to be compiled are listed and also the executable and libraries (so: shared object) are defined.
The appropriate options passed for compiling such directories to include for IDL or c++ header files or for Link
editing phase are listed in the configuration file named “config.mk”, located under /c++ or /java directory,
according to the c++ or java version of the tutorial. The content of these config.mk files can be used as
template to determine the appropriate libraries to load.
4.3 EXECUTING
To execute an example perform the following action
(1) Move to the directory tutorial/c++/<example_name>/run”
(2) Run the script “start.sh”
Using the Deployment Tool
During the Compiling step, archive file containing appropriate components are build for each ccm example.
Running such applications that involve components consists to start some processes among them component
servers that are expected to host components, and also to follow a well-defined steps, for instance to install
assembly, to create assembly and to build assembly. Such tasks are performed using the CARDAMOM
deployment tool that is launched from the script start.sh described above.
35. UNCLASSIFIED
CARDAMOM
61 486 532 AA
CTD
300-2
Date 02/02/2004
E295-06-00012TRL Rev 01
UNCLASSIFIED Page 35 of 192
When started, the deployment tool waits for command (install_assembly, create_assembly, …). For each
example, there are two files named ccm_integration_commands.txt and ccm_stop_command.txt that
contain a set of commands that need to be copied in the deployment tool window as illustrated hereafter:
ccm_integration_commands.txt used for installation and build
DeplTool> install_assembly /TutorialDir/c++/ccm020/i686-pc-linux-gnu/Hello.aar
DeplTool> create_assembly HelloAssembly myAssembly
DeplTool> build_assembly myAssembly
ccm_stop_commands.txt used for des-installation
DeplTool> destroy_assembly myAssembly
DeplTool> remove_assembly HelloAssembly
DeplTool> remove_component Client 1,0,1,0
DeplTool> remove_component Server 1,0,1,0
DeplTool> exit
NOTICE
Two readme files, REAME.txt and README_CCM.txt, are provided to give respectively the list of examples that
access directly CARDAMOM services and those that use CORBA Components facilities provided by
CARDAMOM.
The order in which examples are listed gives an overview of the sophistication that grows step by step from one
example to the subsequent.
36. UNCLASSIFIED
CARDAMOM
61 486 532 AA
CTD
300-2
Date 02/02/2004
E295-06-00012TRL Rev 01
UNCLASSIFIED Page 36 of 192
5. SOFTWARE COMPONENT OVERVIEW
“The whole is greater than the sum of the parts; the part is greater than a fraction of the whole.”
Aristotle
5.1 INTRODUCTION
The Software Component technology makes it possible to build applications from pre-built, off-the-shelf
component implementations.
The Software component architecture makes the value added of the whole application greater than the sum
of the value added of each individual component.
However, highly configurable component model provides component product with flexibility and generality
to be reusable in a wide range of various applications.
The goal of software component technology is to simplify the development of large distributed software
systems. Software components approach enables building applications by integration of independent and
reusable software pieces.
The CORBA Component Model (CCM) is an infrastructure that allows building applications based on the
Component Computing model. To clarify the CORBA Component Model (CCM) concepts it is useful to give
some definition of software component concepts. For this aim, this chapter gives a brief presentation of the
fundamental aspects of software component technologies. We present here some basic notions, while
detailed information can be found in [8][9][10].
5.2 DEFINITIONS
Software Component addresses as well software product line: A component is a stable industrial product.
The application is build by combining instances of component software product. The process of component
assembly and deployment enables component instances customization.
To be a “software component” a software piece has to fulfill certain properties. To enable composition, a
software component adheres to particular component model and targets a particular component platform.
37. UNCLASSIFIED
CARDAMOM
61 486 532 AA
CTD
300-2
Date 02/02/2004
E295-06-00012TRL Rev 01
UNCLASSIFIED Page 37 of 192
The essential concepts of software component technologies are expressed in Clemens Szyperski definition:
“A software component is a unit of composition with contractually specified interfaces and
explicit context dependencies only. Software component can be deployed independently and is
subject to composition by third parties.”
This definition raises the following key points:
The contractual side: a component has a contractual interface.
The explicit context dependencies: a component expresses its contextual dependencies.
Software components are unit of deployment: component are instantiated at deployment time
The component-to-component autonomy: component is unaware of other components.
Contractual interfaces represent the contract between two interconnected component instances. Contractual
interface are relative to the service specification as defined for a given domain or business (or domain)
model.
Explicit context dependencies covers two folds:
o The contextual dependencies over others component contractual interface
o The contextual dependencies over the execution platform.
To clarify the difference we call required interface the expression of dependencies with other components
contractual interface and platform interface the expression of platform dependencies.
Figure 5-1: Component interfaces
Contractual
Interface
Required
Interface
Platform
Interface
Contextual
Dependencies
38. UNCLASSIFIED
CARDAMOM
61 486 532 AA
CTD
300-2
Date 02/02/2004
E295-06-00012TRL Rev 01
UNCLASSIFIED Page 38 of 192
Contractual and Required interfaces definitions adhere to an abstract component model; the platform
interfaces definitions adhere to the execution platform model.
Software Components are deployment unit instantiated at run time. Thus the component instance is for a
component what an object is for an object oriented programming class (Figure 5-2). For an object its class
defines its implementation, for a component instance the “component” defines its implementation.
Figure 5-2: Component instance
However a component instance does not exist as such; what exist are instances of classes defined in the
component implementation. However, in this document we use the term “component instance” to design the
run time aspect of a component.
The component execution platform handles runtime component instantiation. At run time component
instances exhibit component’s contractual interface.
Each component being design independently, it enables to reuse components in different composition
contexts. The component independency is kept by maintaining the decoupling between the contractual
interface and the software component implementation. As well the contractual interface is independent of
the explicit context dependencies definition.
component
Component
instance
aClassaClass
anObject
39. UNCLASSIFIED
CARDAMOM
61 486 532 AA
CTD
300-2
Date 02/02/2004
E295-06-00012TRL Rev 01
UNCLASSIFIED Page 39 of 192
5.3 COMPONENT CONTRACTUAL INTERFACE
Contractual interfaces defines the contract between two components. We can use a client/server view, one
component acting as client and the other as a service provider (Figure 5-3). The service access is described by
the contractual interface. Seeing from another client component the contractual interface is the only visible
interface of a component instance.
Figure 5-3: Contractual Interface
A component contractual interface is defined using an interface description language. To maximize the
component independency it is better to use an object oriented approach to define contractual interface, even
if the component itself has not been designed internally as object oriented; in other words not build with an object
oriented language.
With an object approach the domain object model defines component contractual interface.
5.4 COMPONENT EXPLICIT CONTEXTUTAL DEPENDANCIES
Explicit contextual dependencies describes the components requirement vis-à-vis other components and
execution platform.
Component composition fulfils the component required interface dependencies by connecting a component
instance to other component instances providing the required contractual interface.
Required interface are contractual interfaces required by a component instance in a given context. Two
components presenting the same contractual interface may have a different set of required interface.
The component platform model enables to describe the component contextual dependencies vis-à-vis the
execution platform and technical services of the platform. It brings as well the semantic for component
configuration and customization at deployment time.
Contractual
Interface
Client Server
40. UNCLASSIFIED
CARDAMOM
61 486 532 AA
CTD
300-2
Date 02/02/2004
E295-06-00012TRL Rev 01
UNCLASSIFIED Page 40 of 192
5.4.1 ABSTRACT COMPONENT MODEL
The Abstract Component model defines the rules of component composition. Composition rules are used to
define component interconnection. A set of interconnected components forms a component assembly.
Abstract Component model defines a connection-oriented programming model. This Model defines connection
operations used to connect and disconnect components.
An abstract component model defines an assembly semantic based on component ports. Ports enable
component interconnection using connectors.
Figure 5-4: a Single Component
A set of interconnected component instances makes a component assembly.
Figure 5-5: Component Assembly
Component ports enable to specify the semantic of the link between two components. To express the semantic
of the connection a port may have a gender.
41. UNCLASSIFIED
CARDAMOM
61 486 532 AA
CTD
300-2
Date 02/02/2004
E295-06-00012TRL Rev 01
UNCLASSIFIED Page 41 of 192
Connections semantic are:
Synchronous: the client is blocked until the request completion.
Asynchronous: the client does wait for the request response.
As well, to express relationship direction ports have a gender,:
Emitter: initiator of the request
Receiver: request executor.
Abstract Component Model defines as well the component instances life cycle. Component life cycle is
closely related to component interconnection. Connections are established between component instances not
between components.
As a matter of fact, the Abstract Component Model defines the component connection-programming model.
This programming model defines implicitly the connection life cycle. It addresses matter such as: when and
how to connect, disconnect and reconnect a component instance.
5.4.1.1 COMPONENT ASSEMBLER
The component assembler uses the connection-oriented programming-model. The component assembler is like
a conductor giving order to components during the component life cycle.
The component assembler can be a component as well or a specific service of the execution platform.
Figure 5-6: Component Assembler
Create()
Remove()
Connect()
Disconnect()
42. UNCLASSIFIED
CARDAMOM
61 486 532 AA
CTD
300-2
Date 02/02/2004
E295-06-00012TRL Rev 01
UNCLASSIFIED Page 42 of 192
5.4.2 COMPONENT PLATFORM MODEL
The platform model defines the rules to describe component explicit context dependencies with regard to the
execution platform. The description is based on a Dependencies Description Language.
The platform model encompasses off line and on line element:
Off line elements enable description of software components as unit of deployment.
On line elements address the component deployment and execution.
Off line description are used by on line deployment and execution entities of the platform model.
43. UNCLASSIFIED
CARDAMOM
61 486 532 AA
CTD
300-2
Date 02/02/2004
E295-06-00012TRL Rev 01
UNCLASSIFIED Page 43 of 192
6. CORBA COMPONENT MODEL (CCM)
6.1 INTRODUCTION
In the previous chapter you have seen the broad definition on software components. We are now addressing
the CORBA Component Model. To start with the CCM it is useful to define the link between CORBA
component and CORBA object:
A CORBA component is a set of deployable CORBA objects.
Remember that actually a component instance never exists as such, what exist are the instances of the
classes defined in the component implementation. In the case of CORBA component the instances are
CORBA objects.
According to the definition of a component:
CORBA component contractual interfaces are CORBA objects interfaces.
The required interfaces of CORBA component are as well a set of CORBA objects interfaces.
Furthermore to manage the CORBA component deployment CCM defines an additional CORBA object
the component interface.
The CORBA contractual interfaces are issued from a domain object model. The CCM scope is the explicit
contextual dependencies and component customization.
To manage CORBA component contextual dependencies the CCM defines the following model:
An abstract component model.
An event model
A component configuration model.
A component packaging and assembling model.
A component deployment model.
A server side programming-model.
The main purposes of each model are namely:
The abstract component model enables interconnection of component interface to fulfil the
component dependencies vis-à-vis other components.
The configuration model brings component customisation without altering its implementation.
The packaging and assembling-model allows component shipping as an independent deployment
unit.
The deployment-model makes it possible seamless integration of component or component assembly
to build a distributed application.
The server side programming-model provides component reuse at the source code level.