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
|
<html>
<!-- -->
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Issues with OMG Real-Time CORBA 1.0 Specification</title>
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
</head>
<body>
<h3>Issues with Real-Time CORBA 1.0 Specification</h3>
This document lists what we believe to be the shortcomings of the
Real-Time CORBA 1.0 specification, which we uncovered while implementing it in TAO.
All items on this page refer to <a href="http://cgi.omg.org/cgi-bin/doc?ptc/99-05-03">ptc/99-05-03</a>, which was
the basis for our implementation. This material will be submitted to the
OMG.
<h3>
Unnecessary <i>ClientProtocolPolicy</i> complexity</h3>
<p>
<i>ClientProtocolPolicy</i> can be set on either client or server. Section 4.8.5
in CORBA 2.4 cautions against defining policies that can be set
in both places:
<blockquote><br>
If the <b><font FACE="Arial" SIZE="2">Policy </font></b> can be
used with <b><font FACE="Arial" SIZE="2">POA </font></b>creation
to tune <b><font FACE="Arial" SIZE="2">IOR </font></b>contents
and can also be specified (overridden) in the client, specify how to reconcile the policy's
presence from both the client and server. It is strongly recommended to avoid this
case! As an exercise in completeness, most <b><font FACE="Arial" SIZE="2">POA </font></b>policies
can probably be extended to have
some meaning in the client and vice versa, but this does not help make usable
systems, it just makes them more complicated without adding really useful
features.
There are very few cases where a policy is really appropriate to specify in
both places, and for these policies the interaction between the two must be
described. </blockquote>
<p>While the specification does describe what happens if <i>ClientProtocolPolicy</i>
is set on both client and server, it is not clear that being able to set the
policy on the server-side adds any useful functionality. With <i>ServerProtocolPolicy,
</i>the server already has the ability to specify which protocols and in what
order can be used by clients for invocations. So, <i>ClientProtocolPolicy</i>
should be made a pure client policy, to reduce the complexity of the
system. A related issue, which becomes moot if the policy is made pure
client, is whether <CODE>nil</CODE> <i>ProtocolProperties</i> are allowed in <i>ClientProtocolPolicy</i>,
and, if so, how are they encoded into a <i>TaggedComponent</i> if the policy is
set on the server-side.</p>
<h3>Lack of standard APIs for managing Priority Mappings and Priority Transforms</h3>
<p>The specification does not define APIs for setting and getting Priority Mappings and Priority Transforms,
leaving it up to ORB implementations. These APIs should be standardized in
order for application code to be portable.
</p>
<h3>
Policy configurations ambiguities</h3>
<p>The specification defines a number of policies involving priorities, and
describes some of their interaction. However, it does not completely
specify the validity and semantics of <i>all</i> possible combinations of those
policies. For example, does the combination of Server Declared Priority
Model with server-set Priority Banded Connections make sense? For all values?
If the purpose of Priority Banded Connections is to avoid priority inversions,
then why would we ever want to use <i>PriorityModelPolicy</i> without <i>PriorityBandedConnectionPolicy</i>?
And, if we would <i>always</i> want to use Priority Banded Connections, why does
there need to be a policy, why can't banded connections be a mechanism the ORB
uses internally as needed, transparent to the user? </p>
<p>What is clear from the spec is the availability of certain policies, what is
not clear is what exactly using each one of those policies achieves - in other
words, when and why different combinations of them are appropriate. </p>
<h3>Lack of thread resources model</h3>
<p> Section 4.12.2 of the specification says the following about server ORB and
priority band establishment: <cite>"if the priority band
is inconsistent with the ORB's priority configuration then the ORB shall raise a
INV_POLICY system exception". </cite>However, the specification
never defines what is meant by <i>the ORB's priority configuration,</i> leaving
it up to implementations. One implementation, for example, might use
Threadpool threads for servicing banded connections, and <i>consistency with the
ORB's configuration</i> would mean availability of a threadpool lane with
priority matching band's priority range. Another implementation might be
spawning separate threads for servicing banded connections, and <i>consistency
with the ORB's configuration</i> would be automatic. With these two
implementations, a band that will cause exception in the first implementation
will work just fine in the second. The specification does not provide a
model of ORB thread resources: it provides APIs for creating Threadpools, but
does not describe how the threadpool threads are used. I/O threads are
never even mentioned. On one hand, this lack of a resource model is
beneficial: it allows greater freedom and variety of implementations. But,
on the other hand, it hurts portability, since a configuration might work with
one real-time ORB implementation but not another. Also, bounding priority inversions
is a quality of implementation: there is no explicit requirement for I/O threads to run at the same priority as request processing threads.</p>
<p>In summary, we believe that Real-Time CORBA 1.0 specification is a good
start, but needs some work, especially in regards to resolving
ambiguities. Currently, applications must depend on many implementation details.
For example, a policy combination providing certain semantics in one ORB can
provide different semantics or be invalid when used in another ORB, with both
ORBs being compliant with the specification. </p>
<hr>
</p>
</body>
</html>
|
