TAO/docs/rtcorba/omg_issues.html

   1 <html>
   2
   3 <!--  -->
   4 <head>
   5 <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
   6 <title>Issues with OMG Real-Time CORBA 1.0 Specification</title>
   7 <meta name="GENERATOR" content="Microsoft FrontPage 4.0">
   8 </head>
   9
  10 <body>
  11
  12 <h3>Issues with Real-Time CORBA 1.0 Specification</h3>
  13
  14 This document lists what we believe to be the shortcomings of the
  15 Real-Time CORBA 1.0 specification, which we uncovered while implementing it in TAO.&nbsp;
  16 All items on this page refer to <a href="http://www.omg.org/cgi-bin/doc?ptc/99-05-03">ptc/99-05-03</a>, which was
  17 the basis for our implementation.&nbsp; This material will be submitted to the
  18 OMG.
  19 <h3>
  20
  21 Unnecessary <i>ClientProtocolPolicy</i> complexity</h3>
  22 <p>
  23
  24 <i>ClientProtocolPolicy</i> can be set on either client or server.&nbsp; Section 4.8.5
  25 in CORBA 2.4 cautions against defining policies that can be set
  26 in both places:&nbsp;
  27 <blockquote><br>
  28   If the <b><font FACE="Arial" SIZE="2">Policy </font></b> can be
  29 used with <b><font FACE="Arial" SIZE="2">POA </font></b>creation
  30 to tune <b><font FACE="Arial" SIZE="2">IOR </font></b>contents
  31 and can also be specified (overridden) in the client, specify how to reconcile the policy's
  32 presence from both the client and server. It is strongly recommended to avoid this
  33 case! As an exercise in completeness, most <b><font FACE="Arial" SIZE="2">POA </font></b>policies
  34 can probably be extended to have
  35 some meaning in the client and vice versa, but this does not help make usable
  36 systems, it just makes them more complicated without adding really useful
  37 features.
  38 There are very few cases where a policy is really appropriate to specify in
  39 both places, and for these policies the interaction between the two must be
  40 described. </blockquote>
  41 <p>While the specification does describe what happens if <i>ClientProtocolPolicy</i>
  42 is set on both client and server, it is not clear that being able to set the
  43 policy on the server-side adds any useful functionality.&nbsp; With <i>ServerProtocolPolicy,
  44 </i>the server already has the ability to specify which protocols and in what
  45 order can be used by clients for invocations.&nbsp; So, <i>ClientProtocolPolicy</i>
  46 should be made a pure client policy, to reduce the complexity of the
  47 system.&nbsp; A related issue, which becomes moot if the policy is made pure
  48 client, is whether <CODE>nil</CODE> <i>ProtocolProperties</i> are allowed in <i>ClientProtocolPolicy</i>,
  49 and, if so, how are they encoded into a <i>TaggedComponent</i> if the policy is
  50 set on the server-side.</p>
  51 <h3>Lack of standard APIs for managing Priority Mappings and Priority Transforms</h3>
  52 <p>The specification does not define APIs for setting and getting Priority Mappings and Priority Transforms,
  53 leaving it up to ORB implementations.&nbsp; These APIs should be standardized in
  54 order for application code to be portable.&nbsp;&nbsp;
  55 </p>
  56 <h3>
  57 Policy configurations ambiguities</h3>
  58 <p>The specification defines a number of policies involving priorities, and
  59 describes some of their interaction.&nbsp; However, it does not completely
  60 specify the validity and semantics of <i>all</i> possible combinations of those
  61 policies.&nbsp; For example, does the combination of Server Declared Priority
  62 Model with server-set Priority Banded Connections make sense?&nbsp; For all values?&nbsp;
  63 If the purpose of Priority Banded Connections is to avoid priority inversions,
  64 then why would we ever want to use <i>PriorityModelPolicy</i> without <i>PriorityBandedConnectionPolicy</i>?&nbsp;
  65 And, if we would <i>always</i> want to use Priority Banded Connections, why does
  66 there need to be a policy, why can't banded connections be a mechanism the ORB
  67 uses internally as needed, transparent to the user?&nbsp;&nbsp;</p>
  68 <p>What is clear from the spec is the availability of certain policies, what is
  69 not clear is what exactly using each one of those policies achieves - in other
  70 words, when and why different combinations of them are appropriate.&nbsp;</p>
  71 <h3>Lack of thread resources model</h3>
  72 <p> Section 4.12.2 of the specification says the following about server ORB and
  73 priority band establishment: <cite>&quot;if the priority band
  74 is inconsistent with the ORB's priority configuration then the ORB shall raise a
  75 INV_POLICY system exception&quot;.&nbsp;&nbsp; </cite>However, the specification
  76 never defines what is meant by <i>the ORB's priority configuration,</i> leaving
  77 it up to implementations.&nbsp; One implementation, for example, might use
  78 Threadpool threads for servicing banded connections, and <i>consistency with the
  79 ORB's configuration</i> would mean availability of a threadpool lane with
  80 priority matching band's priority range.&nbsp; Another implementation might be
  81 spawning separate threads for servicing banded connections, and <i>consistency
  82 with the ORB's configuration</i> would be automatic.&nbsp; With these two
  83 implementations, a band that will cause exception in the first implementation
  84 will work just fine in the second.&nbsp; The specification does not provide a
  85 model of ORB thread resources: it provides APIs for creating Threadpools, but
  86 does not describe how the threadpool threads are used.&nbsp; I/O threads are
  87 never even mentioned.&nbsp; On one hand, this lack of a resource model is
  88 beneficial: it allows greater freedom and variety of implementations.&nbsp; But,
  89 on the other hand, it hurts portability, since a configuration might work with
  90 one real-time ORB implementation but not another.&nbsp; Also, bounding priority inversions
  91 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>
  92
  93 <p>In summary, we believe that Real-Time CORBA 1.0 specification is a good
  94 start, but needs some work, especially in regards to resolving
  95 ambiguities.&nbsp; Currently, applications must depend on many implementation details.&nbsp;
  96 For example, a policy combination providing certain semantics in one ORB can
  97 provide different semantics or be invalid when used in another ORB, with both
  98 ORBs being compliant with the specification.&nbsp;&nbsp;&nbsp; </p>
  99
 100 <hr>
 101 </p>
 102 </body>
 103 </html>