1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
|
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"><p>
<!-- $Id$ -->
<html> <head>
<title>Component-Integrated ACE ORB - TODO list</title>
</head>
<body>
<h1>Component-Integrated ACE ORB (CIAO) - TODO list</h1>
The following is a prioritized list of things (with the highest
priority items first) that the DOC group is working on. The expected
date of accomplishments are also added as ETA (expected time of
accomplishment) :
<h3>Things to do:</h3>
<ul>
<li> Integrate TAO's real-time event channel within the
container. Components can use this feature to communicate using
<CODE>eventtype</CODE>s a pub-sub mode. The code is available in a
branch and it needs to be integrated in to the main-trunk. (ETA -
2004/08)
</li> <p>
<li> Allow components (i.e., assemblies) to be connected using the
NameService (ETA - 2004/08) </li> <p>
<li> Allow non-component enabled clients to access reference to a
component or an assembly using NameService (ETA - 2004/08) </li> <p>
<li>Allowing components to set attributes, atleast attributes of
basic types. As a first step we need to implement the
<CODE>StandardConfigurator</CODE> interface. The servant for the
<CODE> StandardConfigurator</CODE> interface should be implemented
and activated by the servant for the component. DAnCE can extract
the reference from the servant and use it to set attributes (ETA -
2004/08)</li><p>
<li>Now that we have supports for ccm_{activate,passivate,remove}, we
need to rethink how a container manages the lifecycle of all the
components/homes it hosts so all the servants related to a
component get destroyed "properly". The aforementioned
SessionComponent operations will also depend on the proper
lifecycle management. <p>
This includes making sure all components' appropriate
ccm_passivate and ccm_remove operations are called when the
ComponentServer is closing down.<p> (ETA - 2004/08) </li>
<li> Migrate RT features from RTComponentServer to DAnCE
(ETA - 2004/10) </li> <p>
<li> Static configuration of components using DAnCE (ETA - 2004/12)
</li> <p>
<li>We need a set of tests to make sure most (and later
all) of the data types are function correctly (in term of CIDL
generated code). More importantly, we need to make sure all the
component keywords are supported okay. (ETA - 2004/07)<p>
<li>The naming convention used in <a
href="new_component.html">creating new component
instructions</a> and that used in <a
href="templates/">templates</a> do not match. (Files containing
glue code are named *_svnt.* and *GS.* respectively.) We need
to address that.(ETA - 07/2004) <p> </li>
<li> Retire the old assembly and deployment framework (ETA -
2004/10) </li>
<li>We need to review the implementation of servant glue code and
container implementations to make sure that they are
thread-safe, if the container calls for it. Currently, these
states are changed only by the deployment framework which always
runs in single thread, so it's not a serious problem. However,
it's perfectly legal to dynamically configure connnections, which
will be the case if we want to add new components or remove
components from the assembly.(ETA - 2004/09)<p>
<li> Add support for creating a thread pool within the the component
server. We don't have support for this, which has made our users
resort to spawning threads within the components, which breaks
portability of the executor code. (ETA - 2004/09) </li> <p>
<li> At present components in an assembly have no way of knowing
whether the assembly is complete or not. This becomes important when
there are hierarchical assemblies, and the assembly at a higher
level needs to pass on attrbute information to the assembly at a
lower level. The spec talks about <CODE> configuration_complete ()
</CODE> whose semantics are a bit unclear. We may have to use this
to inform the components that the configuration is infact
complete. (ETA - 2004/09)</li><p>
<li> We have now two proprietary methods in the <CODE>
SessionComponent </CODE> interface called <CODE> ciao_preactivate ()
</CODE> and <CODE> ciao_postactivate () </CODE> which has to be
overridden by the executor code irrespective of whether the executor
implements them or not. These were added to help components to know
activation status of other components in the assembly. This could
create problems for interoperability of the executor code. A better
to way is to have the CIDL generate C++ code instead of executor IDL.
The generated C++ code from the CIDL could provide default
implementations which could be overridden by the executor code if so
desired. This would make the executor code more portable. Obviously
we also should retain executor IDL generation using some command line
options. (ETA - 2004/09). </li> <p>
<li> Need to develop tools that would allow components to be added
dynamically to an existing assembly and remove components
dynamically from an existing assembly (ETA - 2004/12) <li> <p>.
<li>The CCM_Core libraries need to be refactored so regular CIAO
users no longer need to link to CIAO_Server but to
CIAO_Container library instead. Currently, the session
container implementation is throwing exceptions from the
deployment modules when it fails to install a home. But these
feature should really be implmented in the Deployment::Container
interface instead. (ETA - 2004/12)<p>
<li>HomeRegistrar related files from the CCM_Core projects have
been removed. We need to move them into a new directory when we
get to a new HomeFinder/HomeRegistrar implementation. Notice
that the deployment framework will need to use the HomeRegistrar
interface to register components/homes. (ETA - 2004/12)<p>
<li>We should add support for the unclassified container and use the
property file of some sort to configure the empty container.<p>
Process component (which have 1:1 servant to OID mapping) might
be useful too (no need to support PSS in this case?)<p>
Persistent object references/IDs can be useful for statically
configured DRE systems as they eliminate the initial handshakes
in a multi-process system and enable each process to start up
independently. (ETA - Not known) <p>
<li>The new <code>generate_component_mpc.pl</code> script should
invoke the <code>generate_export_file.pl</code> automatically
and created the necessary export files instead of only printing
out the hints on how to do that. (ETA - Not known)<p>
<li>We need a ConfigValues parser for extracting common name-value
info out of a ConfigValues sequence. This would be needed if
components have to set complex user defined types as attributes.
(ETA - not known). </li><p>
<li><b>Container Factory</b>: We need to provide a container factory
interface to decide what kind of container we need to use. Hmm,
isn't this the job of <code>ComponentServer</code> interface?
(ETA - not known)</li><p>
<li><b>ComponentInstallation</b>: This is a simple interface that
provides (UUID, Location) mappings. Both UUID and Location are
of string type. Since ACE supports UUID implementation, we can
probably use that to generate a UUID. Location should be URI, but
let's just map that to locations in filesystem (pathnames) for
now. So we will most likely need to provide more downloading
mechanisms in the future, e.g., http, ftp, etc. <p>
ComponentInstallation is the interface assembly mechanism used
to interact with the deployment mechanism. We are free to
implement the deployment mechanism (i.e., shipping of code to
various locations of application domains) the way we like but
the assembly mechanism depends on this interface to determine
where to fetch a specific implementation.<p>
One thing that we really need is an installation tool set which
can be used to manage remote installation, by parsing various
XML descriptors and either push or pull the right implmentation
for a certain host in the list of hosts the component need to be
installed. According to the CCM spec., ComponentInstallation
interface implementation can retrieve a implementation (DLL) on
an on-demand basis. Therefore, there is probably no need to
push the appropriate DLL over right away when we feed some
descriptors into the installation tool. The tool, however,
should accurately extract the correct OS/compiler information
and inform the ComponentInstallation impl which and where to
fetch the right implmentation for the host it is running on. (ETA - not
known)<p>
<li><b>CIDL Compiler</b>:
There are no immediate plans to support the part of CIDL
corresponding to the OMG Persistent State Definition Langauge
(PSDL). For an up-to-date status of the CIDL, please see
$CIAO_ROOT/CCF/Documentation/TODO.
<li> This is a set of the to-do associated with the DAnCE implementation.
<p>
<ul>
<li>We need to put the ComponentServer layer back in. In the current
implementation we use NodeApplication as both the Session Container
and the ComponentServer. We need to seperate the two
entities so we can hook any Container with the
ComponentServer. This change is essential to the RT
configuration and for the future of CIAO.<p>
<li>Bala added ciao_[pre|post]_activate to the Session Component to
force the order of actions upon start-up, but this will not
work with the new DnC framework. We need to change the DnC framework
a bit to make this feature available again.<p>
<li>We need to work on the Resource Management process in
DAnCE. Right now this part of the DnC spec is omitted in our
implementation.<p>
<li>We need to work on the packaging process more so we can ship
binaries around when the dll/so is not available in the
local node.<p>
</ul>
</ul>
<h3>Cool ideas</h3>
<ul>
<li>Currently, developing a component will create 3 DLLs, one for
the client side stuff, one for the servant glue code, and one
for the executors. We need to figure out a way to automate
these stuff. MPC is a good starting point to generate scripts
to create project templates.<p>
<li>Management of <code>ComponentInstallation</code> can be done
using a CORBAscript of some sort as this involve mostly
registering and unregistering of locations of component
implementations.<p>
</ul>
<h3>Finished Work</h3>
<ul>
<li>The exception returned from CIAO_Daemon when it fails to
locate a DLL is quite useless to say the least. It needs
fixing.<p>
CIAO now provides more meaningful error message now.<p>
<li>We should create a new workspace/target in TAO such as CIAO_ONLY
to simplify the process of using CIAO. Currently, you have to
checkout the README file in CIAO_ROOT to figure out what TAO
modules are required by CIAO.<p>
A new target "CIAO_Core" is now available in ACE's top level
Makefile.<p>
<li>We need better debug info and a way to control how different
level of debug info are generated in CIAO.<p> Some preliminary
support using the <a href="EnvVars.html">environment
variable</a> <code>CIAO_DEBUG_LEVEL</code> has been added.<P>
<li>Miminal implementation of CIDL compiler.<p>
<li>CCM core workspace now contains 3 different DLLs:
<UL>
<li>CCM_Client - Needed by CCM-awared client
<li>CCM_Container - Needed by executors and servers
<li>CCM_Server - Needed by servers and CIAO tools
</UL><p>
<li>A SessionContainer implementation.<p>
</ul>
</body> </html>
|
