Summary:
IDL4 extends the IDL type system with int8/uint8/map/bitset/bitfield/bitmask, these all could be useful at the CORBA layer so to have guaranteed interoperability CORBA should define the CDR marshaling support for these new types
Currently CCM uses a Cookie which is returned from the connect operations which has to be pased with disconnect. This requires the deployment tooling to store this Cookie at deployment for usage later on at teardown. As each connection has a unique string id in the plan we propose to replace the Cookie with the unique string id which is from the deployment plan. With a connect this string is passed with the connect call, later on with disconnect the same string can be passed again. For all calls that retrieve a struct containing a Cookie we propose to replace this with a IDL map with the string as id , the reference as second value.
These changes make deployment logic/tooling much easier, also now a IDL map is used which makes user code more clean instead of emulating a map with a sequence with a struct where the user has to search themselves.
Problem:
Since CORBA/e is for embedded constrained systems, one should be using LW Services as a minimal compliant point this would still allow one to offer up a Full Services in its offering but the other way around would not be compliant.
Suggested Change
The suggested change is to use LW Services definitions for CORBA/e.
We propose to extend the InvalidName exception with a "string name" member to simplify analyzing problems when this exception is thrown, the exception will tell at that moment the name that failed
The spec should define a standard CompressorId for zstd (see https://en.wikipedia.org/wiki/Zstandard)
Summary: The COM/CORBA Part A spec states that user exceptions go after return values in one place, and before return values in another. (3.2.10.3 and 4.1.3.1)
Summary: (D)IForeignComplexType,(D)ICORBAStruct,(D)ICORBAUnion,(D)IForeignException,(D)ICORBAUserException should have standard UUIDs and UUID identifiers
In chapter 11 'Unreliable Mulicast Inter-ORB Protocol' the struct PortableGroup::GroupInfo is discussed. However in the consolidated IDL and the IDL available from the OMG web site, this struct has been replaced by PortableGroup::TagGroupTaggedComponent. Which is correct?
Summary: When mapping bounded sequences, should the Automation View accept as an in-parameter a Safearray whose upper bound is less than the maximum lenght of the mapped sequence?
Summary: Section 4.1.12: DICORBAtypeCode::kind has one parameter of type TCKind. It should be of type CORBATCKind
Summary: There should be a standard ProgramId for the class which exposes D(I)CORBAAny
Summary: The enum should be named CORBA_CompletionStatus instead of CORBA_ExceptionType
Summary: The VB cannt handle array out-parameters. Must use in-outs.
Summary: Enum CORBATCKind omits the boolean kind (p.4-123, section 4.1.12) I recommend adding it to the end of list to preserve backward compatibility. Also missing tk_char.
Summary: The return value type should be DICORBATypeCode*, not IDispatch. The return value of member_label should be a DICORBAAny* rather than VARIANT
Summary: I suggest that the automation chapter be changed to align with the architecture chapter
Summary: The uuid for DForeignException has an extra 0. It should be E977F907-3B75-11cf-BBFC-444553540000
Summary: This property should be removed because the INSTANCE_repositoryId property in IForeignComplexType provides this functionality
Summary: When translating a BSTR to a CORBA bounded string, boundary violations should cause the View to propagate DISP_E_OVERFLOW
Summary: Second to last paragraph of the section contains the term "CORBA proxy" which should be changed to Automation View Interface.
Summary: The "retval" attribute should be removed from the second argument in both methods. MIDL does not have a retval attribute
Summary: INSTANCE_Clone does not need an in-parameter to specify the instance to be cloned.
Summary: ODL which shows an extra, optional parameter for exception information on property-get or property-set method is erroneous, since MKTYPLIB doesn"t allow extra parameter on property accessor
Summary: There should be a standard name for the Automation View interface.
Summary: Page 2-30, top of page, end of section 2.7.1: There is a label "Examples:" but no example follows
Summary: "..maximum value of an Automation short" should read "..maximum value of a CORBA::UShort
Summary: Above rules seem to imply that the
"safe" keyword identifier can only occur before the first scoped name in the
<value_parent_spec>, whereas I think the actual intent is that it can only
occur before a non-abstract value type, of which there is at most one in the
list, although it need not be the first. Since this can"t be expressed in the
rules exactly, I would simply amend the rule to be:
<value_parent_spec> ::= ":" [ <safe_token> ] <scoped_name>
{ "," [ <safe_token> ] <scoped_name> }
*
and simply express the semantic restriction in the text. There already is a
brief mention of the semantics of the "safe" keyword in section 5.3.2.5
"Substitutability Issues". Perhaps another sentence or two would help clarify
the intended usage.
Summary: The OBV spec (orbos/98-01-18) does not specify which TypeCode operations apply
to Value and ValueBox types. For example, are id(), name(), member_name(),
member_count(), member_type(), etc. valid for Value and ValueBox or should they
raise BadKind exception?
I don"t see why they should not be valid. Normative text should be added in
CORBA 2.2 section 8.7.1 TypeCode Interface to reflect this and the comments in
the IDL should also be updated.
Summary: 2) Attribute "name" in interface ValueMemberDef clashes with attribute "name"
inherited from Contained. A different name should be used, something like
"value_member_name"
Summary: Can a Value type inherit from a Value Box type (the Value Box is described
as been syntactic sugar for a Value type)?
Summary: 1) Can a Value type inherit from a Value Box type (the Value Box is
described as been syntactic sugar for a Value type)? If so, what is the
implicit name of the Value Box"s single data member?
Summary: If number of dimensions of an input SAFEARRAY does not match the mapped CORBA type, the Automation View should generate the HRESULT DISP_E_TYPEMISMATCH
Summary: 1) ValueDefSeq is used in a couple of places but is never defined. A typedef
for it is missing.
Summary: There should be straight dispatch versions of DCORBAObject and DORBObject
Summary: Also, the OBV spec defines a describe_value() operation in interface ValueDef
which returns a FullValueDescription structure. Is there supposed to be another
operation which returns the shorter ValueDescription structure?
Summary: p.6.68: It is a bit awkward that boxed values of "complex" types map
all to the same type (i.e., as for typedefs, the value"s name appears
only in holder/helper classes), and that each boxed value of "basic" type
maps to its individual class. Instead, boxed values of basic types
could map to the corresponding java.lang.* class, e.g.
java.lang.Integer, java.lang.Short, etc. An issue with this approach
is that java.lang.Short and java.lang.Byte are not defined in JDK
1.0.2. I doubt however this JDK is still much in use; for its users,
short and octet could optionally map to e.g. CORBA.ShortValue and
CORBA.ByteValue (inspired from CORBA::StringValue).
Summary: Section 5.4.2 "New lexical type - Keyword Identifier" the statement is made that
"new keyword identifiers should only be added such that the resulting grammar is
still easily parsable, e.g. is LALR(1).". It seems to me that is not true even for
the newly introduced keyword identifiers in many cases.
Summary: 5.3.3: Is it possible to have a value inherit from (ie, support) a
boxed value ? If yes, the Java mapping of boxed values of type
string, sequence and arrays should be changed because String
and arrays can"t be extended in Java.
Summary: If a value type can inherit from a Boxed Value then what is the implicit name of
the Value Box"s single data member?
Summary: Missing member_kind and member_tc
Summary: I have an important issue concerning the C++ mapping and the fact
that application developers need to define/implement the concrete
value class.
Summary: Clarify the exact semantics of computing the hash code and comparison semantics for type equivlanece. (lost email, paraphrase of issue)
Summary: Section 5.6.3 Hashing Algorithm (and 5.6.2)
long long hash = sha[1] << 32 + sha[0]
Summary: Why is the 64 bit hash code at the end of the string and
not at the beginning ? This can speed up the comparison
when two repository Ids are different.
Summary: It is not clear whether the #pragma prefix is still part
of the repository Id. I think it should be.
Summary: 2) How does one find out a RepositoryID for registering a factory or a streaming
policy?
Summary: TypeCodes:
Summary: Clarify the hash code algorithm
Summary: Semantic of register_value_factory is not clear
What do applications should expect if a factory is already
registered for a given repositoryId?
The operation returns the previous factory. But it is not
clear whether it is overriden or not.
Summary: According to the object-by-value C++ mapping, the value type that is
not boxed results in an abstract C++ class. Basically, the reference
counting methods are not provided (abstract). It is the responsibility of
application developer to define/implement a concrete class. Althought
this can be done, there are some issues:
Summary: In the Java mapping example on page 6-64 the operations are mapped to
public operations of the Java class. However in the C++ mapping example on page
7-95, the operations are mapped to protected pure virtual functions of the
generated C++ class.
Summary: What is the rationale for making ValueBase a value and not a native type?
It seems strange to me that a ValueBase "value" maps to java.io.serializable
in Java. Isn"t that what native was invented for?
Summary: The default ref-counting classes are said to be "fully concrete".
Is this really necessary?
What is the semantic of "_copy_value" for the ref-counting class?
=> suggest that "_copy_value" MUST NOT be implemented
(It is implemented by "_copy_value" of the real value type)
Summary: - What is the return type of "_add_ref" and "_remove_ref"
(defaults to "int", but what is the semantic of the result value)
=> propose to change to "void"
Summary: p 5-50, 2nd paragraph of 5.6.2.1: it seems to me that in existing
ORBs, version inconsistencies between, eg, structs, may already corrupt
memory. The difference now is that preservation of values sharing
could make matters worse. It would be great to have this issue better
explained.
Summary: typo p 5-50, first paragraph of 5.6.2.1: *s*IDL compilerS keep on spitting...
Summary: Suggested changes (to section 5.4.1 of orbos/98-01-18) are:
1. Remove the ``;"" from the end of the definition of <value>. (It"s
in the modified <definition>.)
2. Remove [ <supports_token> <scoped_name>
{ ``,"" <scoped_name> }* ]
from the <value_inheritance_spec> non-terminal move it to a new
non-terminal, <value_supports_spec>.
3. Change the definitions of <value_abs_dcl> and <value_header>,
replacing [ <value_inheritance_spec> ] by [ <value_inheritance
_spec ] [ <value_supports_spec> ].
Summary: Given:
abstract interface A {};
interface B : A {};
value C : supports B {};
Can an instance of C be passed by value to an operation that expects an A?
Summary: p 5-24, first paragraph of 5.3.1.3:
The implementation of operations may be remote if the value also
supports CORBA.Object.
typo p 5-30, last line of 5.3.2.6: may BE defined
Summary: A typo: on page 8-107, interface Account should inherit ":" from Describable and
value Currency should support Describable.
Summary:
The Objects By Value (OBV) Specification (orbos/98-01-18) introduced
the concept of "keyword identifiers" in an effort to avoid breaking
existing IDL specifications.
1) First and foremost, the addition of keyword identifiers changes
the IDL grammar into a context-sensitive grammar, which are known to
be notoriously difficult to parse.
Summary: 1) Can the "public" modifier be applied to value operations? What is the default?
Summary: Reconcile RMI/IIOP upcall and helper class
Summary: In Section 5.9.1 on p. 5-55 of orbos/98-01-18, the spec says "the sending context is responsible for listing the repository ID"s for all the base types to which it is safe to truncate the real
type, going up (the derivation hierarchy) to, and including if appropriate the formal type". Currently, there is no portable way to obtain the list of type safe repository ID"s
from within the marshaling engine in order to be marshaled on-the-wire properly.
Summary: The Objects By Value (OBV) Specification (orbos/98-01-18) introduced
the concept of "keyword identifiers" in an effort to avoid breaking
existing IDL specifications. It specifies that a keyword identifier
is a word that is treated as a keyword only when used in a keyword
context, and is otherwise treated as a regular identifier.
3) It allows IDL specifications that, while not unparseable, are
highly ambiguous, especially to a human reader. For example, Jeff
recently posted answers on how the following is to be parsed, but
there is no way that someone reading the OBV spec would be able to
figure out the rules he gave:
interface public
{ ... };;
value safe
; // Is this legal or an error?
value foo2 : safe safe
; // What about this?
value foo3
;
While all of these constructs can all be parsed using the appropriate
number of look-ahead tokens (by the way, the grammar is not LALR(1)
as the OBV Spec suggests), it is hard to read and even harder to
parse correctly. Many IDL compilers still fail to properly implement
the name lookup rules in the existing CORBA specification, and adding
keyword identifiers will only make that situation much worse.
Summary: The Objects By Value (OBV) Specification (orbos/98-01-18) introduced
the concept of "keyword identifiers" in an effort to avoid breaking
existing IDL specifications. It specifies that a keyword identifier
is a word that is treated as a keyword only when used in a keyword
context, and is otherwise treated as a regular identifier.
4) Finally, the keyword identifier approach gives the impression that
IDL extensions can be made at no cost, which is simply not true.
Summary:
The Objects By Value (OBV) Specification (orbos/98-01-18) introduced
the concept of "keyword identifiers" in an effort to avoid breaking
existing IDL specifications.It allows IDL specifications that are simply unparseable. For example:
interface ValueBase {};
struct S
;
This is ambiguous because the compiler cannot know whether the type
of struct member "v" refers to the ValueBase interface or the
ValueBase keyword identifier.
Summary: The OBV spec adds the notion of "chunking" because it claims that "it is
anticipated that value types may be rather large, particularly when a graph
is being transmitted. Hence the encoding supports the breaking up of the
serialization into an arbitrary number of "chunks" in order to facilitate
incremental processing." (orbos/98-01-18, page 5-55)
This "feature" should be removed from the spec, since it is the job of the
underlying transport to handle this issue. GIOP already provides
fragmentation, allowing transports to handle large parameters efficiently
– why should we build yet another fragmentation solution on top of it?
Summary: The "in", "out", and "inout" modifiers on value operation parameters are
effectively comments. This is the case as a value maps to a language
pointer or reference. When it is passed in a local interface
there is no way to guarantee "in" or "out" semantics; it is passed by
reference which essentially has "inout" semantics.
These semantics should be explicitly stated.
Summary: Can the "public" modifier be applied to value operations? What is the default?
In the Java mapping example on page 6-64 the operations are mapped to
public operations of the Java class. However in the C++ mapping example on page
7-95, the operations are mapped to protected pure virtual functions of the generated
C++ class.
Summary: A typo: on page 8-107 of the OBV spec., interface Account should inherit ":" from
Describable and value Currency should support Describable.
Summary: It has been pointed out to me that we have no way of narrowing
from abstract interfaces to non-abstract interfaces and value
classes. In Java, the helper"s narrow method has a signature of
org.omg.CORBA.Object, so it cannot take an abstract interface
type. In C++, the generated classes for abstract interfaces
have an _narrow method with the right signature (taking an
AbstractBase_ptr), but generated classes for values and regular
interfaces don"t have such a method. It seems like we would
need to add overloaded narrow methods in all these places to
make this work as envisaged in (for example) numbered paragraph
3 of section 8.3.
Summary: Section 5.3.1.2 says that non-public data members should be mapped
so that "the private part of the state is only accessible to the
implementation code and the marshaling routines."
Section 6.3.1 says that non-public data members are mapped to
private instance variables.
The problem is that the Java marshaling routines are in the Helper
class, which cannot see private instance variables in the value class.
The proposed solution is to modify the Java mapping to map the default
IDL state to the default (package visibility) Java state instead of
private.
Summary: Using the idl defined in Issue # 1352, we have the send() method, in interface Foo, which takes a Base value type as it"s formal parameter. Now supposet we wish to pass a Derived value type. When marshaling the list of repository id"s, the marshaling engine has no notion of the formal type of the parameter , thus it
does not know how many safe repository id"s it needs to marshal.
Summary: One of the common patterns used in IDL specifications is to pass a
sequence of a data type in order to cut down on network round trips.
The current OBV spec (orbos/98-01-01) even suggests sending a graph of
objects and optimizing for the case where the same object occurs
multiple times in the graph (which I assume will normally be a small
number of the total objects). The spec seems to be inefficient for
sending a large number of small objects though. I have looked at the
errata before and don"t recall any relavent changes but know the RTF are
considering some now.
Summary: Section 5.8.6 gives the BNF for the GIOP encoding of values but does not
describe the semantics behind them. Some of the semantics are referred
to in earlier section and intuitive for an outsider with a little CORBA
experience. Some of the the explicit semantics seem to be missing
altogether (e.g. the "" in <end_tag>). It would be useful if the
descriptions explicitly used the names within the BNF grammar or
explicit specifications for each name in the grammar was given.
Summary: It is not clear from the spec whether or not value boxes can be
forward declared, and used recursively. For example,
value v;
struct s
;
value v s;
If value boxes are indeed syntactic sugar, the answer should be yes.
That brings the next question: Does this mean that one can call
create_box_value_tc(), supplying NULL for the original_type, and
then later on fill in the member typecode via fill_in_recursive_tc,
supplying a ValueMemberSeq of length 1?
Summary: The spec does not contain a clear definition of how TypeCodes for
values and value boxes are constructed. There is something about
this in section 5.6.3, but this seems to describe a variant of the
algorithm rather than the algorithm itself. Section 5.9.7 needs to
be expanded to describe this in at least as much detail as the
description of the encoding of recursive sequence TypeCodes in the
current CORBA spec.
Summary: The OBV spec allows a value to support multiple interfaces. In C++, such
values
are specified to derive from the POA skeletons generated from those
interfaces.
This presents a potentially intractable problem: skeletons are not designed to
be inherited together with skeletons for other interfaces because servants do
not support multiple interfaces. (The Multiple Interface RFP isn"t finished
yet, right?) The top of page 20-104 of the latest C++ mapping (orbos/98-05-08)
explicitly says
Summary: 1) The fill_in_recursive_sequence_tc method is intended to act
upon an existing "tk_value" TypeCode. The signature indicates
that it should return a TypeCode pointer.
What TypeCode is supposed to be returned ?
If the signature is in error, the specification should
be corrected – if not, the specification requires
some additional explanation as to which TypeCode
needs to be returned.
Summary: 2) In addition to the ValueMemberSeq, the input parameters to
fill_in_recursive_sequence_tc include the target TypeCode
pointer, and the RepositoryId.
What is to be done with the RepositoryId parameter ?
Is the method supposed to update the Id as well ?
If that is the case, is it an optional/required parameter ?
Summary: The OBV spec defines CDROutputStream and CDRInputStream types values for
custom marshaling. The names of these types should not contain "CDR" since
there is nothing that prevents them from being implemented to use a data
representation other than CDR.
Summary: On page 5-44, a new production has been added to the grammar to allow the use of ValueBase to be used as a base type. (<base_type_spec> ::= ... | <value_type_spec). My concern is that all other types of base type specifiers have a PrimitiveKind. However, either you guys forgot or didn"t want to have, that a value or ValueBase does not have a corresponding PrimitiveKind enum value. This becomes essential later on when we want to go into the InterfaceRepository, and find that some type is a ValueBase, we will need to know this. The easiest way to do this could be through a PrimitiveDef, where it"s def_kind attribute is a dk_Primitive, and to satisfy the IDLType interface for they type attribute, we could return a TCKind of tk_value or tk_ValueBase. An alternate could be to not go the PrimitiveDef route and use a different approach. Perhaps we could have a method in the Container or Repository interfaces called create_ValueBase. This would be much like creating an unnamed type such as a sequence, a string, primitive, or array (i.e. get_primitive(), create_string(), etc. in the Repository interface). This is less likely though because create_ValueBase would need to return a type. We could return a ValueDef, but create_ValueBase wouldn"t have enough information passed to it to create on and besides, a ValueDef is named. We could have a whole new definition interface called ValueBaseDef, but this way is a pain if you ask me.
Summary: Section 5.9.7 of orbos/98-01-18 says that the TypeCode parameters for both
tk_value and tk_value_box start with a string which is the type"s
repository ID. Why? For everything except tk_interface, the repository ID
is not visible as a parameter. I believe these parameter lists should not
include repository IDs to make them consistent with the others.
I assume that the
{member_name, TypeCode} pairs in the tk_value parameter
list should appear in the order of declaration of the members in the
valuetype. This is not stated anywhere.
The visibility of each member should be added to the tk_value parameter
list. Each entry in the list should contain
where the short refers to the Visibility of the member.
The parameter list for tk_value should probably have an additional
parameter which is the TypeCode of the concrete valuetype base, if any.
Summary: There are no typecodes for abstract interfaces. Does this mean
that abstract interfaces cannot be members of structs, unions,
or values? If so, I think this is a problem and we should add
typecodes for abstract interfaces.
Summary: 1. There are no write_Abstract and read_Abstract methods on
DataInputCtream and DataInputStream. This looks like an oversight
to me.
Summary: The custom marshalling streams CDRInputStream and CDROutputStream
don"t support the IDL fixed type. I propose adding the following
type definition and methods:
typedef sequence<fixed> FixedSeq;
abstract value CDROutputStream
{ ... void write_fixed (in fixed value); void write_fixed_array (in FixedSeq seq, in unsigned long offset, in unsigned long length); };
abstract value CDRInputStream
{ ... fixed read_fixed (); void read_fixed_array (inout FixedSeq seq, in unsigned long offset, in unsigned long length); };
Summary: The OBV spec is not very clear about whether the Java class
generated for an IDL value has a default (no-argument) constructor.
A no-argument constructor is needed so that the Helper class
can construct a value when demarshalling. However, it should be
package-private in order to limit its visbility to the Helper
class and not expose it to client code. This is also true for
state fields declared as private in the IDL value type (which the
spec currently states are mapped to private in Java).
Summary: For boxed values that are structs, unions, or other constructed types with
member accessor and modifier functions, their member functions such as
value(), boxed_in(), boxed_inout(), etc. may potentially clash with the
names of those accessor and modifier functions.
Solution: make the names of such special member functions start with an
underscore, e.g., _value(), _boxed_in().
Summary: There"s a problem with the mapping to Java for boxed IDL values
for non-primitive Java types, for example, a boxed string or a
boxed sequence. The currently specified write_Value call doesn"t
allow these to be marshalled correctly.
Summary: The OBV spec orbos/98-01-18 introduces a new repository ID
mechanism. It says in 5.6.2.1
>> We don"t recommand the classic id format "IDL:" <scoped name> ":"
>> <major> "." <minor> because it is not "foolproof" enough. (It is of
>> course allowable to use this format, since the CORE specification
>> does not mandate any particular form.)
The last sentence is not entirely correct, as 8.6.4 of formal/98-02-33
specifies
>> A definition is globally identified by an OMG IDL - format
>> RepositoryId if no ID pragma is encountered for it.
The issue is whether the OBV specification changes this default for
values or not
Summary: 2. The current language mapping mixes both generated code with user
written code in the same source file. This poses a very complex "tool"
issue for IDL compilers which is unnecessarily complex.
Summary: 5. The ValueHelper interface contains the method get_safe_base_ids, which is
inconsistent with current OBV terminology.
Summary: The OBV design for the "CORBA::tk_value" TypeCode defines a
potentially recursive constructed type that involves ValueMembers.
The "tk_value" TypeCode defines the entire complexity of the types
within the Value.
It is our understanding that when the ORB code that handles "Anys" for
C++ detects a tk_value TypeCode and needs to encode/decode the associated
Value object – (e.g., for Any::replace(TypeCode, void *) – it will
need to invoke a method on that object that understands the object
instance data and the associated state information. Further
examination of the TypeCode complexity will not be necessary by the
Any implementation, since this code would not have knowledge of or
ability to set the state information within the Value object itself.
The reason why the layout of the state information within a value
cannot be known by external code is that virtual inheritance of
abstract values and/or abstract interfaces makes it impossible to
calculate the offsets of the data members in a compiler
independent manner.
Summary: There are no rules governing how to free value factories in C++.
Specifically, the ORB does not know what to do with the value factory at
shutdown, and applications do not know what to do with the factory
returned by register_value_factory. Directly deleting the factories may
be hazardous (e.g. if they are shared across multiple valuetypes or even
multiple ORBs), and leaving them around may introduce memory leaks.
Summary: The OBV spec introduces the concept of initializers, which maps
cleanly only to languages that support overloaded constructors.
Other languages, such as C, would typically offer functions to provide
inialization of values. Since initializers are not named, an intuitive
mapping is hard to find.
Summary: The definition for interface CodeBase in module SendingContext
has a method
CORBA::InterfaceRepository get_ir();
There is no type CORBA::InterfaceRepository. I believe this was
intended to say
CORBA::Repository get_ir();
Summary: The submission makes no mention of HTTP tunnelling. There are many
firewalls which filter HTTP, FTP and email related traffic. Is the
omission based on the assumption that such firewalls will comprise
a CORBA conformant GIOP proxy on a well-known IIOP port? The Bi-
directional GIOP specification suggests not (section 5-1,
paragraph 2).
Is tunnelling regarded as an implementation matter? If so there
will be important issues such as relaxing GIOP/HTTP mapping and
security which the specification should clarify.
Summary: Problem: There is a general problem on how to specify sending an empty
Transaction PDU, such as an empty BEGIN, or an empty CONTINUE. "Empty"
means just the Transaction portion without ROS components. This problem has
to be addressed for sending an empty Transaction PDU from the CORBA side,
as well as what to do when such a PDU is received from the legacy domain.
Summary: Problem: Title does not cover the use of SS7 as signaling transport. This case is
not a TC interworking.
Summary:
I would like to get some clarification on the PASSTHROUGH/Untrusted Proxy
issue.
In page 4-45, the spec says "It is possible to support pass-through through
multiple proxies. For example if in the above example there was another
proxy B2 between B and C, during processing the new_target operation from A,
B can try to establish a pass-through connection to C via a call to
new_target on B2. If this fails, due to NO_PERMISSION for example, B should
fall back to try to connect through B2 using the NORMAL mode.".
If the connection (B - B2) is NORMAL, the whole connection is not a
PASSTHROUGH since the client will see the B2"s identity in the SSL session.
Should B throw back the NO_PERMISSION to the client if B get NO_PERMISSION
from B2 for PASSTHROUGH connection? If the answer is no (seems to me that is
what spec says), does this mean that it is possible that the client request
a PASSTHROUGH connection but actually get a NORMAL connection?
Summary: The issue comes from the following configuration:
Client - Tcp Firewall - Giop Proxy Server - Server
The server"s IOR will contains a FirewallComponent, which includes two
FirewallMechanisms - a TcpFirewallMechanism and a GIOPProxy. The issue
comes when the GIOP Proxy has multiple profiles, which may have different
host/port, and the TcpFirewallMechanism can only have one host/port. Does
that mean for any host/port specified in one of the GIOP Proxy "s profiles,
you always to connect to the host/port specified in the
TcpFirewallMechanism? This seems unrealistic since the Tcp firewall usually
provide a one-to-one mapping.
Summary: Chapter 5 - Bi-directional GIOP misled me in a number of points, even after
numerous readings and a discussion with an author. I believe the chapter
contains all the pertinent information; it just has to be a bit more
carefully presented.
Summary: The firewall spec defines a number of tag values from OMG managed spaces.
The values of these tags need to be assigned.
Summary: The Minimum CORBA submission describes exactly what should
be present in minimum CORBA (basically CORBA 2.2 including
the POA) in IDL/PIDL.
However, the Java language mapping in CORBA 2.2
does not include the POA -> just the APIs for registering
transient objects.
One cannot even take recourse to CORBA 2.3 to get the
language mapping, since much stuff (OBV, Java to IDL etc.)
was added in the intervening time. There does not seem to be
any existing document which documents a Java language mapping
of CORBA 2.2 including POA without lots of other stuff.
Summary: Problem: It is not necessary to have uniqueness of Invoke Ids within a dialog.
The invoke id can be reused as soon as it is no longer active.
Proposed solution: Put in text following the discussion of management of invoke
ids in the TC spec.
Summary: Section number: 3.5.1.1, item 4 plus appropriate section of interaction translation
Problem: How to handle the sending of an empty RESULT and the reception of
such a component.
Proposed solution: Obviously no way to change the IDL from void. Need
something in the TC Repository for use by a gateway in deciding what to do.
Summary: Issue: 5
Section number: 3.5.1.1, item 3
Problem: We have mistakenly associated TcLinkedContext with the operation
which has the LINKED keyword rather than the actual linked operation, i.e., the
operations appearing following the LINKED keyword
Summary: Section number: 4.2.1
Problem: How can we bound the range of invoke ids in the IDL? Q773 requires
invoke ids in the range -128 to 127. ROS has no limits.
Summary: It should be possible to have negative invoke ids.
Summary: Problem: make factory creation operations conform to the IDL style guide
Proposed solution: change the capitalization and put in underscores between
words
Summary: Section number: 4.3.1.2
Problem: Title and text should be changed to reflect that it is dealing with creating
an association rather than initiating a dialog.
Summary: Section number: 4.7.1
Problem: Is it necessary to indicate that RelativeRoundTripPolicy is not
propogated to the server? Also does TC interworking require the support of the
priority policies?
Summary: Section number: 4.2.1
Problem: Why is AssociationId a string? Should one explore the possibility of
using a combination of values supplied by both the initator and responder.
Strings do not seem to be the most scalable solution.
Summary: Section number: 4.2.2
Problem: There is a difference between the responder and initiator interfaces
because the initator cannot support the new association operations.
Summary: Section number: 4.2.1
Problem: The current text for DialogFlowCtr is for outgoing only. It should be
updated to reflect incoming messages from the legacy domain.
Summary: Section number: 5.4.1
Problem: DialogPortion should be a union rather than a struct. The complete IDL
is correct.
Summary: Section number: 7.1, page 108
Problem: Shouldn’t it be typedef string CORBA::ScopedName?
Summary: Section number: Fig. 27
Problem: Shouldn’t GwTcPduHandler be replaced by GwTcPduProvider?
Summary: Section number: 5
Problem: Shouldn’t this section really be called TC Service Interface because it
really provides an IDL version of Q.771? Note that this requires changing the
names of various interfaces by removing the word Pdu, which should be
reasonably simple.
Summary: Section number: 5.2 and other sub-sections
Problem: The encapsulation BerData could potentially hold ASN.1 encoded via
other rules like PER. So is this name misleading, or too restrictive?
Proposed solution: One choice is EncodedData.
Summary: In ptc/98-10-11 15.8 from the end of the fourth paragraph "any
requests from the server on an objects exported by the client to the
server via this connection will be sent back to the client on this
same connection." to the eleventh paragraph "If the client initiates a
new connection it is not foreseen here that the server can use that
connection for requests on the object exported previously." it seems
to be implied that a reference must be passed via a connection if that
connection is to be used to invoke the referenced object with
Bi-Directional GIOP.
Summary: Problem: Use UML to express relationship of interfaces.
Summary: Section number: 6.1
Problem: Should SIOP version number start with 1.2?
Proposed solution:
Rationale: This would allow a quick recognition of the highest GIOP version supported by
this version of SIOP.
Summary: Section number: 5.4.4
Problem: There is no way to send dialogue data in a continue confirm.
Summary: Section number: 6.2.2
Problem: sccp_version should be changed to SIOP_version. Also the word
"agent" should be changed to "server."
Summary: Section number: 5
Problem: There is no way to associate more than one instance of a TcPduUser
with a GT/AC pair for incoming SS7 messages.
Summary: Section number: 6
Problem: Could SIOP be changed to 7IOP, pronounced "seven-up"?
Proposed solution:
Rationale: The S in SIOP may be mistaken for Security.
Summary: In orbos/98-07-03 4.9 it says "However, it is desirable to provide a
portable means by which the object implementor can decide whether an
object could be accessible through a firewall. The following POA
policy is defined for this purpose:" but this policy can at most
control what components are included in references created by the
POA. Since the references do not have any mechanism to defend against
forgery, exclusion of a FirewallMechanism component does not prevent
access through a firewall. If an attacker obtains some other reference
with the FirewallMechanism component(s), it can convert a reference
created under NO_EXPORT into the reference that would have been
created under EXPORT.
The description of the policy needs to be changed to make it clear
that the policy does not imply any access control enforcement. The
ability of an attacker to forge references, either by combining parts
of other references, or otherwise, should be explicitly stated as a
security issue that must be addressed by means outside this
specification.
Summary: Section 4.7.4 - description of new_target operation.
The first para states:
"The new_target operation informs the firewall that it should prepare itself
to
receive requests destined for the specified target. The object returned
from this
operation is the destination on the firewall to which a request on the
target should be
sent i.e. the object_key in the return object should be used in the GIOP
request header."
and the last para says:
"The object returned by the new_target operation must contain an object key
which
allows the proxy to uniquely identify the target. A client is not required
to open a new
connection to the proxy server, even when the target object(s) are located
in different
servers."
The last sentence implies that the IOR returned from the new_target has the
same host/port number as the GIOPProxy. This may not be true. For example if
a firewall is load balancing across ports and network interfaces, the
host/ports may be differnt, and in this situation a new connection is
required.
Summary: OMG document orbos/98-07-03, section 4.7.4 under new_callback page 4-16,
the first paragraph reads
When the client side object adapter creates the object reference for the
callback object, it may invoke the
new_callback operation on the outermost inbound GIOP Proxy on the server
side and pass the callback object as the argument.
Say, there are no client-side firewalls and there is only one
server-side GIOPproxy firewall.
1. how does the object adapter or the client orb get access to the IOR
of the GIOPProxy object ???
2. how does the object adpater know that the object that is being
created/instantiated will be used as a callback
object ??
Does POA provide any m
Summary: The description of firewall traversal in orbos/98-07-03 4.11 has some
significant unstated assumptions, and prescribes an algorithm that has
several flaws.
In orbos/98-07-03 4.11 it says: "A client will determine if it needs
to go through a firewall to make a request on the target object. If
the client is in the same domain a direct invocation can be made. The
client can determine this be examining the host address information in
the target IOR." This assumes that the enclave structure maps to host
addresses in some way known to all clients. This needs to be made more
explicit.
Summary: In ptc/98-10-11 5.8.1 it says "If a client has not set up any mechanism for
traditional-style callbacks using a listening socket, then the port entry
in its IOR must be set to the outgoing connection"s local port (as
retrieved using the getsockname() sockets API call)". At IOR creation time
there may be no connection, or there may be many, so the mandated local
port may be non-existent or ambiguous.
This topic was discussed on the firewall-rtf list during Feb-Mar 1999 but
was not raised as an issue.
Summary: The remark about masquerade at the end of ptc/98-10-11 15.8 is not
explicit enough. This is an important security issue and it needs to
be made explicit that a malicious client may claim that its connection
is Bi-Directional for use with any host and port it chooses, in particular
it may specifiy the host and port of security sensitive objects.
In general, a server that has accepted an incoming connection has no
way to discover the identity or verify the integrity of the client
that initiated the connection.
Summary: Proxified object references obtained by invoking
new_target() should not be passed between ORBs. Instead the original IOR
containing the target and firewall information should be passed. The reason
for this is that the IOR does not contain enough information to inform the
second ORB whether or not it is a reference for a NORMAL or PASSTHRU
connection, or whether it is a proxified reference at all. This issue is
very tightly related to issue 2, so we will describe how it fails for each
of the possible solutions to the PASSTHRU establishment problem outlined in
issue 2.
One solution for which this is not an issue is the solution
of using a port per target. However, this is not a viable solution because
it is restrictive and will fail under moderate load. For solution 1 we
don"t have a problem because no object reference is returned by
set_target(), therefore it cannot be passed to other ORBs. For solution 2
we have a problem because the second ORB won"t know whether it is supposed
to first invoke start_passthru() or simply start making requests. Therefore
it may get a connection type that it wasn"t expecting. For solution 3 we
have a problem because once the original connection has been made, the
reference is invalid. This occurs because the firewall does not have
knowledge of how many clients are expected to try to connect to that target,
and it may attempt to claim that port for reuse before another client has
connected.
Proposed Solution:
The passing of object references obtained by invoking
new_target() should be expressly prohibited by the specification. One
example is, "The object reference returned by new_target() may not be passed
to another client. Instead the original reference that was passed as the
argument to new_target() must be passed to the second client, and the second
client will follow the rules of the traversal algorithm to reach the desired
target."
Summary: Description:
Clarification is needed on the passing of credentials.
Section 4.7.3 states that "Since all proxies will have access to the IOR of
the target object, and the certificate of the client, they can judge whether
this client may use a pass-through connection or not." Section 4.12 states
that "When a client establishes a normal connection to a target via a
trusted proxy and uses a secure transport (e.g. IIOP/SSL), in order to
achieve end-to-end authentication, the proxy will have to forward the
client"s certificate/identity to the server." Section 4.12 implies that the
ForwardedIdentity service context will only be used when using a secure
transport, but section 4.7.3 implies that the client certificate will always
be available. In fact, the ForwardedIdentity service context should only be
used in the case of a NORMAL connection using a secure transport because
those are the only conditions under which there is a notion of trust between
a requestor and the recipient of that request. This means that the only
mechanism upon which to base a decision of whether or not to allow a
PASSTHRU connection is the source host address/port.
Summary: Description:
Reusing PASSTHRU connections by the firewall should be
expressly disallowed by the specification. With the current wording of the
specification, a vendor may attempt to reuse PASSTHRU connections. While
this will work in some cases, it is not interoperable because there are
cases when reusing PASSTHRU connections will not work. For example,
connection reuse when SSL is in use will not work because all of the
information that distinguishes data streams is contained within the
encrypted portion of SSL packets. If two SSL connections try to share a
single connection, there will be an SSL protocol failure because the server
will not be able to separate the data streams before it processes the SSL
packet.
Summary: Description:
The specification does not outline a specific method by
which to obtain the initial reference to the GIOPProxy object. We believe
that an interoperable solution for obtaining this initial reference is
needed in order to insure that all implementations will be able to be
correctly configured to contact all other implementations.
As the interfaces currently stand, there is a minimum of 5 CORBA calls
per transaction
1. either TcPduProvider::get_dialog_id
or TcPduProviderFactory::create_tc_pdu_provider
2. TcPduProvider::invoke_req
3. TcPduProvider::begin_req
4. TcPduUser::end_ind
5. TcPduUser::result_l_ind
Given that a CORBA call is about 1 millisecond on average,
this makes for a highly inefficient interface from a high-performance
perspective,
and renders the distribution of these interfaces undesirable, and the
use of the TcPduProvider/User interfaces unlikely in a real system.
Ideally this should be reduced to a minimum of 2 CORBA calls, one for a call
going out, and one for the reply.
There is an assumption in the design that there is a one to one
association between a TcPduUser and a TcPduProvider
during a TC Session. This is enforced in the IDL through the
call
TcPduProvider::get_dialog_id()
and the factory call
TcPduProvider create_tc_pdu_provider(
in TcPduUser user,
out DialogId d_id)
raises(NoMoreDialogs);
Since the TcPduUser reference (or some sort of reference)
is not passed over in get_dialog_id(), the only conclusion
is that the reference has to be the one passed over in the
create, and therefore that each TcPduProvider is tied to
one and only one TcPduUser.
The Specification Translation from ASN to IDL does not appear to
require that each OPERATION carries a NoMoreAssociations exception.
This is necessary if the use of DialogFlowCtr can implicitly create a new
association during a call on an object that supports multiple associations.
Summary: Description:
There may be some network topologies where the traversal
algorithm is not sufficient for a firewall to find a server. This is due to
an unstated assumption that all addresses within the outermost inbound
firewall are addressable from the outermost inbound firewall. Consider for
example the following topology:
| -----*Firewall B*-----Network B Internet ----- |
| -----*Firewall C*-----Network C |
Service Network (DMZ)
Assume that the addresses on the service network are
globally routable addresses, Network B uses RFC 1597 addresses and Network C
uses RFC 1597 addresses. This topology could be possible, say for a
government agency that has sub-agencies that share some resources (service
network) but maintain separately administrated networks. In this case the
outermost inbound firewall for a server on Network B or C is Firewall A.
However, when new target is invoked on Firewall A, it won"t know from the
host address whether to open a connection to Firewall B or Firewall C.
Proposed Solution:
There are several possible solutions to this problem:
1) Explicitly state the assumption described in the
description section
2) Mandate that implementations allow for the
configuration of the next inbound firewalls
3) Mandate that servers on Network B or C in such
configurations use Firewall B or C as the outermost inbound firewall.
There may be other solutions to this problem. These were
the ones that immediately presented themselves.
Summary: Issues 7-9 refer to problems with routing and/or traversal of firewalls.
These problems arise due to a lack of required information about firewall
topology in the IOR. Most of these problems could be eliminated if it were
required that the servers place the entire chain of server-side firewalls
that must be traversed into the IOR. Specifically, the first paragraph in
section 4.8 should be modified so that the entire chain of firewalls is
always required, or those situations in which it should be required should
be stated. Some of those situations are outlined in the following issues.
Specifically, it is incorrect to state that "strictly it is only necessary
to convey information on the outermost inbound firewall."
The creation of a TcUser interface with multiple associations does not have
a standardised way for destruction.
Proposed solutions
1. Add a destroy() method to TcUser
2. Explicitly state in the RFP that the CosLifeCycle::destroy() method should
be called once the object is no longer required.
The idl is
struct TcLinkedContext
{ DialogFlowCtr ctr; InvokeId ivk_id; InvokeId lnk_id; AssociationId a_id; };
While it is correct that these are both of the same type, the name of the type
could be confusing.
I am a little confused as to the scope of the BiDirPolicy in the 2.4.1
specification. Is the BiDirPolicy a POA policy, an ORB policy, or both? In
section 15.8 paragraph 5 on page 15-55, the specification states:
"If the client ORB policy permits bi-directional use
of a connection, a Request message should contain an IOP::ServiceContext
structure in its Request header, which indicates that this GIOP connection
is bi-directional."
but then in section 15.9 paragraph 4 on page 15-59, the specification
states:
"In the absence of a BidirectionalPolicy being passed in the
PortableServer::POA::create_POA operation, a POA will assume a policy value
of
NORMAL."
but then again in the next sentence the specification states:
"A client and a server ORB must each have a BidirectionalPolicy with a value
of
BOTH for bi-directional communication to take place."
Could someone clarify for me what the intent for the scope of the policy was
here, and what the rationale behind that decision was? We are currently
reviewing how to use/fix BiDirIIOP in our submission to the firewall RFP,
and I would like to understand the issues regarding the scope of the BiDir
policy.
While editing the changes from the Firewall RTF into Core Chapter 15 I noticed a
curious thing in the Firewall RTF report. It seems that the RTF chose to re-use
a PolicyType id for a new and different policy while obsoleting a published one.
The PolicyType Id in question is 37, which used to be BIDIRECTIONAL_POLICY_TYPE
associated with the structure BiDirPolicy::BidirectionalPolicy
and is now proposed to be BIDIRECTIONAL_INVOKE_POLICY associated with structure
BiDirPolicy::InvokeMode.
This appears to me to be a dangerous practice, since the fact that the published
standard may have been implemented by someone using the obsolete definition.
I would like to suggest that the recommendation of the Firewall RTF be modified
leaving the published policy type and policy as is with a note stating that it
is obsolete, and a new policy type id be allocated for
BIDIRECTIONAL_INVOKE_POLICY.
Align SIOP definition with GIOP 1.3 of CORBA2.3.1.
Problem: SIOP is currently defined to carry GIOP messages with version 1.2
and lower.
Proposed Solution: Allow GIOP 1.3 messages to be transported.
There are security tags mentioned in the SIOP
document but no definition of how to use them is ever given.
As far as I can see when using the 1988 TCAP version the submission
does not seems to handle the case where the subsystem number (SSN) is
used to seperate between several TC-User protcols per GT (typically
protocols from different vendors). The naming tree proposed for the
1988 TCAP protocol can only store one TC-User protocol per GT, that is
only one DefAc per GT can be stored (see section 4.3.1.1 in the
proposal).
The use of the SSN number for this purpose is explained in chapter
4.2.3 in the second paragraph in the ITU Recommendation Q.775.
It should be easy to fix this as one only have to use the same naming
tree structure proposed for the 1993 TCAP version in these cases.
There seems to be a discrepancy in the changes proposed to CSIIOP and CSI modules. The draft document has identical changes to both. I think the intent of the Errata was to have only one, just switch them from CSIIOP to CSI. However, Brian's convience document doesn't show the change. Now, the draft document ptc/2004-01-01 that we are voting on has both. What to do? Should that be represented by another document, namely CSI, with it's changes, just like 2004-01-02 is? Cheers, -Polar
Yeah, I see the problem. Yet another consequence of the adopted spec changing existing spec without calling out the change in the section meant to identify changes to existing specs. So it looks like the fix involves: 1. Section 1.9.2 and 1.9.3 in ptc/04-01-01 [henceforth referred to as document A] should disappear. 2. The first half of section of document A starting from the second para of the section and upto and including the last but one paragraph on page 1-20, should be appended to Section 24.2.5 "Identity Token Format" of Chapter 24 of Core with the title (that is the CSIv2 Chapter)[henceforth referred to as document B]. Also append a row to table 24-2 with info about ITTCompundToken. 3. The IDL in section 1.9.3 of document A should be merged properly into the IDL for the CSI module that appears in section 24.9.2 document B. 4. The addition to CSIIOP IDL as it appears in Section 1.5.2 of document A should be merged appropriately into the IDL for CSIIOP in section 24.9.3 of document B. 5. In document B insert a section 24.5.1.6 "TAG_IIOP_SEC_TRANS" with a two liner explanation of what this tag is together with the IDL for it from section 1.5.2 of document A. I'd suggest that we file this as an issue and resolve it in the FTF roughly along the lines suggested above.
The following paragraph raises an interesting issue. If we follow this to the letter
From the second paragraph on page 1-30 of the Firewall Final Adopted Spec (ptc/04-04-01):
This document supercedes the previously adopted CORBA firewall specification. In
addition, the changes to bi-directional GIOP, specified in Chapter 15, supercede the
adopted specification for bi-directional GIOP. These specifications are not backwards
compatible with the previous specifications and they are intended to make it possible
to create a functional protocol for the interoperation of ORBs and firewalls.
The BidirectionalPolicy insufficient for persistent objects.
The BidirectinoalExport Policy is a POA policy and it only has two values
of ALLOW and DENY. If it is ALLOW, then a TAG_BI_DIR_GIOP componenet
should be placed in the IOR. It is stated that the ORB must generate a
random identifier when the POA is created. However, that will not work for
persistent objects in which the BiDirectional Offer must remain constant.
Also, there is no default specified if this policy is not placed on a POA,
and no default for the RootPOA.
As I understood it, the Firewall Traversal specification was to use new
CSIv2 Compound Identity types to give the target server the complex
principal composed of the client and the authenticating firewall traversal
path. The server was to be authenticated to the client in much the same
way. This functionality appears to be missing in the specification. It is
easily fixed by returning a CSIv2 IdentityTokenSeq from a successful
firewall negotiation, specifying the backwards firewall authentication
trail from the server to the client.
i have a few questions about the POA ThreadPolicy type
MAIN_THREAD_MODEL.
first, the 2.4.1 spec (00-11-03), sec 4.2.3.2 , 'perform_work' states,
"If called by the main thread, this operation performs an
implementation-defined unit of work; otherwise it does nothing."
how is a distinguished main thread supposed to be reliably determined?
i'm not sure we really need to define this. i'd think what we're trying
to say is that the thread that calls perform_work() is the thread that
will be used to do the work, and it is up to the application to make
sure this happens. in section 4.2.3.3, the spec states,
"For maximum portability an application should call either run or
perform_work on its main thread."
to me it seems the intent is to let the application determine what the
'main thread' is.
second, what happens if an application calls both run & perform_work?
and what happens if the application calls run from multiple threads? it
isn't really clear what the difference in request handling with regard
to the thread used is between run() & perform_work().
right now the spec seems to imply through the use of the message loop
example in section 4.2.3.2 that perform_work is really intended to be
used to handle situations where a single thread must be used for all
application activity. now add to that the note on pg 11-12 about using
the main thread model:
"Note - Not all environments have such a special requirement. If
not, while requests will be processessed sequentially, they may not all
be processed on the same thread."
my interpretation is that ORB::run would be used in cases where you
simply want the POAs to be accessed sequentially, but the application
doesn't care about which thread the implementation uses, but you would
need to call perform_work to specifically hand the application defined
main thread to process requests.
my suggestion (finally ;^) is that we should state perform_work should
be called, on whichever thread the application likes, if it wants to
hand a specific thread to the ORB to do work. otherwise, calling
ORB::run from any thread simply means the implementation is free to
handle requests for servants associated with main thread model POAs on
whatever thread the implementation may choose (including a new one), in
keeping
with the requirement that the requests be processed on each POA's
servants sequentially..
one more question: does it make sense to state that a callback type of
architecture won't work when using this threading model?
The NegotiateSession message is a single typed GIOP message that is sent
between both Client and Server to negotiation service contexts, and
further to initiate and negotiate bidirectional GIOP.
Having a single message is problematic in that a connection, once
negotiated bidirectional may have different requirements for such things
like Codesets, etc. Getting a NegotiateSession message after a
bidrectional set up, the endpoints will have difficulty discerning the
orientation of the NegotiateSession message.
At the very least NegotateSession messages should have an orientation,
much like the GIOP Request and Reply messages do.
I'm not so sure they must be correlated with a "request id", but different
message types would help. I would suggest two messages,
NegotiateSessionRequest and NegotiateSessionReply to maintain the
client-server orientation, respectively.
The Negotiate Session message is unwieldy in that if it is used to send
service contexts, there are no general ways to govern its use other than
by special rules, all of which special cases are not accounted for in the
specification.
For example, when do you sent Bidirectional service contexts as ooposed to
firewall contexts? Can you send transaction contexts? Codesets? Codebase?
CSIv2? Can you send BiDir service contexts while firewall contexts are
being processed?
I'll use the following example to explain the implications that I derive from my understanding about the spec. I hope that it makes sense to you. If I'm wrong, please let me know.
Suppose I set up a client that has some POAs with BI_DIR_EXPORT policy ALLOW. The client wants to invoke a server that accepts bi-directional GIOP. This invocation will cause callbacks to a few objects on the client using bi-directional GIOP. The server is not allowed to create new connections to the client.
In the code of my client application, I can simply use the following statement to invoke the target object. And I would expect that the target object will call back some of the objects on the client ORB during this invocation.
obj = ...; // target
obj.invoke_target(...);
In order for the above scenario to work, I derive the following implications from the spec.
1. This invocation requires the target to call back on some of the objects on the client ORB. Because the client ORB has no knowledge about what objects might be called back, the client ORB has to ensure that the BiDirIds on all of its POAs that have EXPORT policy ALLOW must be available at the server side.
This conclusion also implies that the client ORB may have to track what BiDirIds that have been sent (and accepted) over every connection that allows bi-directional GIOP in order to figure out what BiDirIds have not yet been sent, assuming that you don't want to send all BiDirIds in every request. Furthermore, when someone creates a new POA with the EXPORT policy ALLOW later on the client ORB, the next new invocation on each bi-directional connection will also have to transmit the BiDirId for this new POA to the server side.
2. When the server receives a GIOP Request with BI_DIR_GIOP_OFFER service context, the server cannot dispatch the request to the target object implementation until this connection becomes bi-directional. Why? If the server dispatches the request before this connection becomes bi-directional, this request may fail because the target is not able to call back objects on the client ORB. In the case of Strong BiDirIds, the server may even have to send CHALLENGE and wait for RESPONSE before the server can dispatch the request.
If we put both implications together in the case of Strong BiDirIds, when someone creates a new POA with EXPORT policy ALLOW on a client ORB, a longer delay will be expected in the next request on every bi-directional connection because the server has to verify the BiDirId of this new POA no matter whether this new BiDirId will be used for callbacks on that connection or not. To me this overhead is not acceptable if it is the only way to implement bi-directional GIOP according to the spec. I hope the spec can be written in a way that allows efficient implementation, though efficiency is not always a concern for everyone.
PROBLEM:
The second paragraph on page 15-60 of the revised GIOP chapter only allows a BiDirOfferContext to be sent to a server if the ORB-level policy permits it:
"If the client ORB policy permits bi-directional use of a connection, a Request or
NegotiateSession (see MARS/04-01-01) message can be sent to the server that
contains a BI_DIR_GIOP_OFFER IOP::ServiceContext structure in the header that
indicates that this GIOP connection is bi-directional. The BiDirOfferContext
indicates to the server that the objects with the supplied BiDirIds are available for
invocation over that connection. To determine whether an ORB may support bidirectional
GIOP, the BidirectionalOfferPolicy has been defined (see Section 15.9,
"Bi-directional GIOP policy," on page 65)."
This, however, contradicts the rest of the document, which allows the ORB-level policy to be overriden at the object level. ("A BidirectionalOfferPolicy can be applied to a client ORB, and it can be overridden
for specific object references received by the client ORB." - Section 15-9, page 15-66).
Additionally, the first sentence of the above paragraph is worded in such a way that it defines a connection as bidirectional before it has accepted as such by a server.
Finally, a spurious reference to the submission document is included in the first sentence ("see MARS/04-01-01").
RECOMMENDATION:
Rephrase the paragraph as follows:
If the effective BidirectionalOfferPolicy of an object in the client is set to ALLOW, a Request or NegotiateSession message that contains a BI_DIR_GIOP_OFFER IOP::ServiceContext structure in the header can be sent to the server, offering bi-directional use of the connection. The BiDirOfferContext indicates to the server that the objects with the supplied BiDirIds are available for invocation over that connection. To determine if bidirectional GIOP may be supported, the BidirectionalOfferPolicy has been defined (see Section 15.9, "Bi-directional GIOP policy," on page 65).
If a service context negotiation fails by way of the NegotiateSession
message in either direction. how does the sender (client or servers side)
get an indication back to the sender?
Does Codeset come before/with/after BiDir negotiation?
Does Codeset get negotiated in only the other direction?
If so, will that happen in Negotiate Session meesages orRequest Messages?
On a connection in which BiDir is negotiated, but no Codeset
is negotiated, will the reverse direction be able to negotiate
code set?
Does the CodeSet get negotiated in Negotiate Session?
If so, does Codeset continue to get negotiated in Requests?
Can Codeset come before/with Firewall Traversal in Negotiate Session
meesages?
The new BiDir spec is not clean about what BiDirIds shall be send to what connections. Because the BidirectionalOfferPolicy is either ALLOW or DENY, the only way to make bi-directional GIOP possible is to send all BiDirIds on an ORB to every connection that is used by an object reference that has effective BidirectionalOfferPolicy ALLOW. Besides, when a new POA with BidirectionalExportPolicy ALLOW is created, the BiDirId of this new POA must be transmitted to the server side of every existing bi-directional connections (before or in the next request).
The above implication derived from the spec is very inefficient. Consider an ORB with n bi-directional connections and m BiDirIds. The communication overhead for sending these BiDirIds is (m * n), while, in the ideal case, the communication overhead for sending BiDirIds is (c * n) where c is the average number of BiDirIds needed on each bi-directional connection. This ideal case can be easily achieved by allowing the BidirectionalOfferPolicy to specify a list of POAs whose BiDirIds shall be transmitted.
Proposed resolution:
1. Extend the choices of the value field of the BidirectionalOfferPolicy:
ALLOW_ALL – same as ALLOW now, but the implication shall be explicitely stated in the spec
ALLOW_LISTED – a list of POAs being provided in the policy
DENY – same as it now
2. Add a field to the policy to allow a sequence of POAs being specified.
PROBLEM:
The BiDir GIOP document allows all of the contexts that can be found in a GIOP query or response message to be also allowed in a NegotiateSession message. However, the interplay among these contexts is undefined. An example is the use in NegotiateSession messages of both CodeSet negotiation and BiDir connection setup. What can be used in what order is not defined.
RECOMMENDATION:
Only bi-directional GIOP and firewall contexts may be used in a NegotiateSession message in this version of GIOP. The contexts are the following:
· BI_DIR_GIOP_OFFER
· BI_DIR_GIOP_CHALLENGE
· BI_DIR_GIOP_RESPONSE
· BI_DIR_GIOP_ACCEPT
· FIREWALL_PATH
· FIREWALL_PATH_RESP
Further contexts may be added to new versions of the BiDir GIOP spec as their interplay with the existing set and the order of their use is carefully analyzed and documented. This effectively limits the scope of the problem to the bidir protocol and use by the firewall. The order and stage of processing the above contexts is discussed in another Firewall issue.
The title of Section 1.7, End-to-End Secure Connection, is misleading. There is no end-to-end security in the firewall traversal spec. All security mechanisms described in this spec are essentially mechanisms between a client, firewalls, and a server, not end-to-end. Thus, it is susceptible to the man-in-the-middle attack.
I'm saying we should fix the problem, but the title of this section and the caption of Figure 1-4 is certainly misleading. Besids, if the firewall traversal scheme described in the spec is actually susceptible to the man-in-the-middle attack, we may want to consider stating it somewhere in the spec rather than making people have a wrong impression that it is secure
PROBLEM:
The BiDir GIOP document specifies that all BiDirIds must be randomly generated. However, persistent POAs must use the same BiDirId across sessions since they are stored in the IOR.
RECOMMENDATION:
A new policy is created (BiDirIdGenerationPolicy) that contains two fields:
field 1, the ID generation method, will take the value 'RANDOM' or the value 'REPEATABLE'
field 2, the ID type, will take the value 'STRONG' or the value 'WEAK'
The random generation method is adequately documented. The repeatable method will always generate the same BiDirId for a given POA. This effectively makes the ID a constant, but without the concern for storage. It also results in the end-user not having to deal with BiDirIds - they are handled entirely by the infrastructure.
The values for the ID type indicate whether the type of BiDirId generated is strong or weak.
This policy is placed on the client ORB and/or the POA in question.
PROBLEM:
The BiDir GIOP document does not specify the connections over which a BI_DIR_GIOP_OFFER should be sent.
RECOMMENDATION:
A BI_DIR_GIOP_OFFER will be sent over all existing bi-directional connections. If there are none, then a new connection will be established and its bidirectionality initiated.
PROBLEM:
The actions that result from the failure of a BiDir challenge are unclear.
RECOMMENDATION:
The client has proven itself untrustworthy. A BI_DIR_GIOP_RESPONSE containing a STRONG_FAILED result is returned to the client and all bi-directional connections to the client are closed.
PROBLEM:
The BiDir GIOP document does not specify which BiDirIds and how many of them are sent in a BI_DIR_GIOP_OFFER.
RECOMMENDATION:
All unoffered BiDirIds are supplied in a BI_DIR_GIOP_OFFER.
ptc/04-04-06 section 15.9.1 (top of page 15-67) states:
When the server receives a BI_DIR_GIOP_OFFER context it must send back a
BI_DIR_GIOP_ACCEPT context in both the strong and weak identification cases.
What happens if an ACCEPT service context is not returned? Either immediately
or ever?
Can a connection initiator, having sent an OFFER SC, send any further GIOP
messages over that connection prior to receiving the ACCEPT SC?
Should a connection initiator, having sent an OFFER SC but not having received
an ACCEPT SC, accept a Request (i.e in the reverse direction) on that connection?
a) for an object whose POA's BiDirId has been offered and accepted?
b) for an object whose POA's BiDirId has been offered but a corresponding
ACCEPT has not yet been received?
c) for an object whose POA's BiDirId has been offered and accepted only over a
different connection (to that over which the Request arrives)?
d) for an object whose POA has a BiDirId but it hasn't yet been offered?
e) for any object (e.g. one whose POA doesn't have a BiDirId)?
If an OFFER SC is sent on a Request message, can the corresponding ACCEPT
SC be carried on any GIOP message from the connection acceptor?
a) the associated Response
b) a Response not associated with the Request
c) a NegotiateSession message
d) a Request message for an object whose POA's BiDirId has already been
negotiated
If an OFFER SC is sent on a NegotiateSession message, can the corresponding
ACCEPT SC come piggy-backed on any GIOP message (that can carry SCs) or
must it come over a NegotiateSession message?
If two POAs (with EXPORT policy) are created and their BiDirIds are sent separately
in OFFER SCs on separate messages over a given connection, is a subsequently
received ACCEPT SC deemed to relate to one or to both of the offered BiDirIds?
Since I assume that a connection is effectively promoted to BiDir once the first
ACCEPT SC (indicating no error) is received. What is the point of insisting that
the connection acceptor "must" send additional ACCEPT SC?
In fact, even wthout any ACCEPT(no error) SCs, the occurrence of a GIOP Request
message from the connection acceptor would imply that the connection acceptor
has accepted the BiDirId. It would seem that the ACCEPT(no error variant) SC is
completely superfluous.
Given the ambiguities in the protocol, it seems likely that an implementation may
find the real-world interactions to have broken its model of the protocol. What should
a GIOP protocol machine do in such a situation?
If the connection initiator deems that the OFFER-ACCEPT protocol has gone wrong
should it be required to close the connection?
As there is no correlation between OFFER SCs and ACCEPT SCs, on a given
connection, does an ACCEPT (indicating an error) imply that the connection is
in an indeterminate state and should be closed?
If a connection is to be closed due to an error in the OFFER-ACCEPT protocol do
the normal rules regarding outstanding invocations apply? Do they apply for both
directions?
Part of this issue has been surfaced in the discussions over the mail list. I now file it as an issue.
The Bi-directional GIOP spec says, "An object reference with a BidirectionalOfferPolicy of DENY must not be invoked over a bi-directional
connection." Satisfying this policy requirement does not close some potential limitation and ambiguity when other policies or policy instances are around.
For example, at the connection initiator side, we may have two object references one of which has BidirectionalOfferPolicy of DENY and the other has BidirectionalOfferPolicy of ALLOW. If these two object references point to the same server, according to spec, we need two connections to the server: one is bi-directional and one is not. However, having a non-bi-directional connection doesn't mean much. For invocations on the object reference with the DENY policy, the server side can always callback using the other bi-directional connection.
There is an argument (by Brian Niebuhr) saying that it's not realistic to both trust and not trust the same server. However, in practice, it's not always possible to tell whether two object references point to the same server or not. Furthermore, the client may decide whether or not to trust the server of an object reference depending on reasons other than the information about the server. For example, the client may decide to use BidirectionalOfferPolicy of ALLOW or DENY according to the source of an object reference.
On the other hand, at the connection acceptor side, things become a little more interesting. For an object reference with BidirectionalAcceptPolicy of ALLOW and effective BidirectionalOfferPolicy of DENY (e.g., the default policy on that ORB), what shall be the proper behavior of the ORB? According to the BidirectionalAcceptPolicy, "the ORB may accept and use any connections that a client has offered as bi-directional." However, shall we let the BidirectionalOfferPolicy of DENY prohibits the use of such a bi-directional connection? Or shall we allow the use of such a bi-directional connection because it's in the "reverse" direction?
This issue was mentioned by Dave Stringer. I now file it as an issue.
When a bi-directional connection is established between a connection initiator and a connection acceptor, the connection acceptor may have to consider this bi-directional connection is volatile, i.e., the connection acceptor may lose (and is not able to resume) its capability of making invocations on such a connection anytime. For example, the connection may be lost due to network problems or the client may close a connection due to an idle time-out. These situations are not a problem for uni-directional GIOP because the ORB who wants to make an invocation can always initiate a new connection when the old connection is not available.
This problem may be less serious when bi-directional communication occurs only during the period of an invocation from the connection initiator. In other words, if the connection is lost and results in the failure of bi-directional "callback", the connection initiator may retry, effectively resuming the bi-directional connection.
On the other hand, for the use case in which a connection initiator "registers" an object reference to the connection acceptor, there is no guarantee that "callbacks" from the connection acceptor to the connection initiator will eventually succeed, assuming the network is not always down.
If this issue is a limitation that cannot be solved easily, we should spell it out in the spec.
The connection_complete field of the FirewallPathRespContext is under specified.
The fourth paragraph (including IDL) from the end of Section 1.5.4, Firewall Service Context, says,
“Once the connection has been established, the last intelligent firewall in the FirewallPath sends a FIREWALL_PATH_RESP service context in another NegotiateSession message.”
However, the last paragraph of this section says that, when the connection is not completely established, a FIREWALL_PATH_RESP service context with the connection_complete field of false is sent.
Furthermore, when the connection_complete field is false, the spec does not explain what are the situations that may cause incomplete connection establishment and what the client shall do for “further processing”. Shall the FIREWALL_PATH_RESP service context also contains information indicating what the client shall do?
The Bidirectional GIOP spec does not specify how many BI_DIR_GIOP_OFFER service contexts are allowed in a NegotiateSession or Request.
If only one such service context is allowed, it shall be stated clearly. Besides, because each BI_DIR_GIOP_OFFER service context can contain only either strong or weak BiDirIds (but not both), if there are both strong and weak BiDirIds on the ORB, the ORB has to use at least two GIOP messages to send them all.
If we allow multiple BI_DIR_GIOP_OFFER service contexts in one message, we'll have a problem in matching BI_DIR_GIOP_ACCEPT service contexts to these offers because there is no sequencing on offers and accepts.
PROBLEM:
The target (ORB, POA, object, thread) of the Export and Offer policies and the side of the connection involved is incompletely specified.
RECOMMENDATION:
Define the two sides of a connection as the connection 'Initiator' and connection 'Acceptor'. The usual terms of 'client' (Initiator) and 'server' (Acceptor) become confusing in a bi-directional situation. Given those terms for each side, specify that the Export and Offer policies are used on the Initiator side. Specify that the Export policy may be applied to the ORB, the POA and/or to the thread. Specify that the Offer policy can be applied to the Initiator ORB, to a reference in the Initiator for an object in the Acceptor, or to a thread in the Initiator ORB.
PROBLEM:
It is not defined what happens if a non-conformant implementation receives a BiDir offer.
RECOMMENDATION:
State that a non-conformant implementation need not do anything - it may simply ignore the offer.
PROBLEM:
The BiDir GIOP Document discusses three stages of connection setup, but it is unclear when each stage begins and when it ends. It is also unclear what NegotiateSession or Firewall activity can take place in each stage and what the order of processing may be.
RECOMMENDATION:
Rewrite the relevant portions of the document to specify the following (excerpted without edit from Brian Niebuhr's discussion of NegotiateSession contexts and the stages of setup):
"...during connection setup, only firewall contexts can be in the negotiate session message, NOTHING ELSE. After the connection is setup, there is a period before the first request or locate request where we can do session setup items. I think that in that period, only Bidir contexts can be sent, NOTHING ELSE. The first request or locate request indicates the connection_established period. Again, during that period I think only the Bidir contexts should be legal. This makes things very simple. There are no conflicts between firewall and bidir, and nothing else can go in a negotiate session message."
Summary: What happens when multiple calls are made to Stream::externalize() at the top level? Does the stream contain all those objects, and how does a client discover this?
Summary: The standard stream format should specify that it is portable across different ORBs and hardware, but not across streamable object implementations whch use different semantic content.
Summary: Several LifeCycle methods take a "key" argument, but do not clarify whether multiple NameComponents are allowed in a key, if ordering matters, etc.
Summary: The Externalization spec does not state how a stream implementation is to discover that a context exists when internalizing an object.
Summary: The standard stream data format does not define tags to be used to identify the beginning and end of a context.
The discussion on when to send BiDirIds over connections is floundering.
In part, I think this is due to a lack of precision in our thinking (and more
importantly in the adopted firewall spec we are working from).
When does a GIOP connection become bi-directional? The implementation
of the connection-initiator protocol engine must know this. Before this
event it has to treat a GIOP Request message as a protocol error and after
the event it has to dispatch the request.
There seems to be an assumption (or more than one) that there is a
relationship between an Object Reference (i.e. the programming language
artefact representing CORBA::Object) and a GIOP connection.
Whilst it is true that an implementation of the CORBA spec will provide a
relationship (else an invocation cannot result in a GIOP Request message)
the particular relationship was left to ORB implementers to provide for
flexibility of implementation. Specifically, such a relationship is not prescribed
in the CORBA specification (nor should it be).
I suggest it would be dangerous to define a GIOP connection to change state
when an Object Reference that (in some ill-defined way) "points to" a server
that is the target of that connection, undergoes a policy change (i.e. its BiDir
Offer policy is set to Allow).
Instead, a GIOP connection presumably becomes bi-directional when an
invocation on an Object Reference, with an effective Offer Policy of Allow, results
in a Request message being sent over that connection.
The specification must be explicit over which event causes the connection to
become bi-directional.
Also, can a connection cease to be bi-directional? For example if either the
Object Reference invoked above or the POA with "Export = Allow" are destroyed.
Again this would appear to be fraught with problems, leading to the assumption
that the GIOP connection, once bi-directional, remains bi-directional until it is
closed.
Lastly, the closing of idle connections and the subsequent re-connection has
hitherto been a matter for ORB implementers (Messaging::RebindPolicy not
withstanding). This is unfortunate as an application won't be aware of the ORB
having conserved resources in this way and the ORB should not be expected to
provide session semantics that span multiple tcp connections (this is currently
stated in the description of NegotiateSession).
Summary: CosTransactions Coordinator does not have any IDL method to remember LockCoordinator. How does it know what Lock Coordinators should be informed to drop locks?
Summary: For a non-transactional client who wants to get a LockCoordinator, what input values should one use for the "which argument?
Summary: It is not clear whether CosTransactions::Coordinator is responsible for freeing locks at the end of a transaction.
Summary: In a non-transactional lock request, the lock identity is supposedly based on thread ID. How can the server code get the client thread ID when they may be on different machines?
Summary: If the ORB suffered a communication failure while LockSet::lock() is being called, how does the client know if the lock was granted or not?
Summary: If the ORB times out while LockSet::lock() is being called, how does the client know if the lock was granted or not?
Summary: When Node::externalize_node is called, is node responsible for externalizing related object? What happens, if related object isn"t a CosStream::Streamable?
Summary: When reading a stream, there is no way of telling where context (limited to calls to begin_context and end_context) end and a new one starts.. Resolved problem with new "tag-byte" 0xFF.
Summary: If CosGraphs::deep propagation value is encountered, is the Node"s related object supposed to get copied, too. What if LifeCycleObject delegates to CosCompoundLifeCycle::Operations?
Summary: The second pass of operation is to "cause the node and all of its roles" to be copied. How do you get related object of the NEW roles to be the New Node?
Summary: It seemed more useful for the concurrency service to be non-IDL, and just based on local thread identification.
Summary: The IDL for internalizing roles could be optimized to reduce the size of the externalized data as well as simplifying the implementation
Summary: In lock duration of Section 7.1 there are two descriptions. The role of the clients is vague to me
Summary: In the specification, "Related lock sets" appears only in "create_related()" and create_transaction_related()" Where do I use these methods
Summary: When internalizing a relationships, how do the "shallow" nodes and roles get included?
Summary: There is inconsistency regarding which model ConcurrencyControl needs to support
Summary: Role in new node are disconnected It"s role of read_graph to correctly establish new relationships. How is that accomplished?
Summary: On CollectionObj->remove_element_at(IteratorRef), how does the collection "know" the index?
Summary: How do IteratorObjs and CollectionObjs share state?
Summary: Circular refrences to CosStream and CosCompoundExternalization,
i have not been able to find an idl compiler that can compile
these modules.
as aside, i have foud many syntax errors in the IDL you provide
as CORBAServices98-03-02.idl, in many of its interfaces, there are
typos, and it is not correct with the specifications.
Summary: I assume that we are allowed to scope membership in a collection via an interface test (e.g, must be rooted off of Collection) and throw an InvalidElement exception?
Summary: Using collection factories, can you add multiple elements at once, and/or add new create methods?
Summary: Clarifications on interfaces which support QueryableCollection.
Summary: Can an iterator "reset()" throw an exception such as IteratorPositionInvalid if it is wrapping a db cursor which has no facility for reset?
Summary: Is it correct to offer the vanilla collection methods and add a new set for keyed access?
Summary: Can an interator have a next_n()? Or is this supposed to be via subtyping the interface?
Summary: Where are the destroy methods on the Iterator or on the Collection?
Summary: What does the IteratorPositionInvalid exception mean? Is it only that the user has cycled through the list elements and that no reset() has been issued?
Summary: How does the Iterator know to become invalid when the Collection is altered?
Summary: Need all operations on the Collection be made using the SQL-92/QOL-93? If so, how is it possible to handle flat file datastores?
Summary: Section 11.4.2 para. 3 says that FieldValues may be NULL. What if my datastore is a flat file without a concept of NULL. Does NULL take on the value of empty string for flat files?
Summary: Is there a way that I can delegate the functionality of the Iterators to the RDBMS itself?
Summary: Several of the bullets in section 11.1.5 are unclear.
Summary: How does this operation work?
Summary: Is it not possible that objects in a collection could have changed in between calls to the iterator accessing them?
Summary: Appendix D states that a challenge structure consists of the MD5 of the arguments, but does not specify how the arguments are laid into a stream of octets for the MD5 algorithm.
Summary: When using iterator operations like adding, inserting, etc., how are changes reflected back to the datastores?
Section 23.14 of the CORBA/IIOP 2.4.1 specification lists the
complete IDL for a minimumCORBA implementation. However, the text in
the chapter and the IDL are inconsistent, for example, section 23.4.2
reads:
------------------------------------------------------------------------
---------------
The is_a operation is omitted so as not to introduce a requirement
either for holding
detailed type information in the object reference or for getting type
information over
the wire. Instead, minimumCORBA relies on design time resolution of type
checking
issues.
The non_existent operation is omitted, because of the design philosophy
of making
more decisions statically at design time.
The create_request operation is omitted, as the Dynamic Invocation
Interface is
omitted.
Summary: in section 4.9.2 last paragraph:
"Such a ProxyPushSupplier is guaranteed only to invoke operations defined in
interface I. Any event on the channel that does not correspond to an
operation defined in interface I is NOT passed on to the consumer. Such a
ProxyPushSupplier is therefore an event filter based on type".
My question is: if we have this proxy to block generic calls (push() in this
case) why does TypedPushConsumer inherit CosEventComm::PushConsumer, whish does
support push() ? Why should the generic calls like push() be blocked anyway
if (according to 4.7.1) TypedPushConsumer should support both typed and generic
models ?
Is there something I am misunderstanding ?
>You write on page 18-51:
>In COM V2.0, interfaces can have single inheritance. However, as opposed to
>CORBA,
>there is a standard mechanism by which an object can have multiple interfaces
>(without
>an inheritance relationship between those interfaces) and by which clients can
>query
>for these at run-time. (It defines no common way to determine if two interface
>references refer to the same object, or to enumerate all the interfaces
>supported by an
>entity.)
>
>It's not right, that there's no common way to determine if two interface
>references refer to the same object. The IUnknown-Pointer of two different
>interfaces of the same object must be the same (object identity in COM).
Summary: Issue regarding implementation of the Query IDL specifications on a Java ORB. Issue involves implementing following idl definition from the CosQueryCollection module
Summary: I understand the params to be name value pairs of columns and the values for the
selection, update, delete, insert criteria
what is in the query? I would think if this is the whole query why would you
need the params??
Summary: It is not believed that the spec ever defines what a "malformed" PropertyName is. The closest definition is in para on page 26, section 5.1.1.2 and is not much help
Summary: Need the OQS have any interface with the POS? I don"t see how the two can be interfaced.
Summary: I can"t find in the COM/CORBA spec parts A and B any mention of how to
deal with IDL identifiers that are keywords to the Microsoft "mktyplib" tool.
This tool mangles the following identifier (not necessarily a complete list) by
prepending them with "_":
"BSTR", "CALLCONV", "coclass", "CY",
"CURRENCY", "DATE", "DECIMAL", "DISPID", "DISPPARAMS",
"dual", "EXCEPINFO", "guid", "GUID",
"HRESULT", "importlib", "IDispatch",
"INTERFACEDATA", "IUnknown", "LCID",
"METHODDATA", "odl", "oleautomation",
"PARAMDATA", "properties", "propget", "propput", "retval",
"SAFEARRAY", "SAFEARRAYBOUND", "SCODE",
"VARIANT", "VARIANTARG", "VARIANT_BOOL",
"VARTYPE", "VARENUM"
As far as I can tell, the output of the "mktyplib" tool makes use
(directly or indirectly) of the regular C++ bindings, whose identifiers
are not mangled the same way. This makes it impossible to emit COM bindings
for IDL files that contain the above keywords.
The problem that I"m running into is in CosTrading IDL, where the identifier
"properties" is used.
Page 2-7 of the CosExternalization Service Specification (April 2000)
defines the following interfaces:
CosStream::Node
CosStream::Role
CosStream::Relationship
A CosStream::Node inherits from the CosStream::Streamable interface and
therefore is a streamable object – it has an external_form_id attribute
that enables a FactoryFinder to recreate the object using the
create_uninitialized operation.
Unfortunately, the CosStream::Role and CosStream::Relationship interfaces do
not support the CosStream::Streamable interface and therefore are not
"streamable;" in particular, there is no standard method to obtain a KEY for
them when it is time to internalize them.
Perhaps, I am missing something (it wouldn't be the first time 
, but
having them support the Streamable interface would certainly make
implementation much easier. Might I suggest the following:
interface Role: CosGraphs::Role, CosStream::Streamable
{ ... }at a minimum this would permit the CosStream::Node internalize_node()
operation and the CosStream::StreamIO read_graph() operation to use a KEY
value in the FactoryFinder to instantiate the object, before it is
internalized.
Summary: There is a bit of confusion in the specification concerning the
exceptions that are possible during the internalization process.
The internalize operation can raise CosLifeCycle::NoFactory and
StreamDataFormatError exceptions. This operation calls the
internalize_from_stream operation of the Streamable interface that can
raise the CosLifeCycle::NoFactory, StreamDataFormatError, and
ObjectCreationError exceptions.The last paragraph on page 8-20 (August
1997 release) states that the ObjectCreationError and
StreamDataFormatError exceptions of the internalize_from_stream
operation originate from the read_object amd read_<type> operations on
the StreamIO interface. However, the ObjectCreationError is not raised
by any of these, according to the IDL in figure 8-6.
I develop CosConcurrencyControl service for JacORB, but I don't
understud from specification how client can destroy LockSet.
When I create Object which allow concurrency access, I create LockSet.
When I destroy this Object I must destroy LockSet, because it's garbage,
bu no way for this does not exists.
As solution of this problem, I add in CosConcurrencyControl.idl next
changes:
exception LockExists{};
and method
void destroy raises (LockExists);
in interface LockSet.
As I undestand this changes is wrong, but have you idea about desigion
this problem.
Summary: Existing software based on messages with ASNI format description and a future version based on IDL. Does anybody know something about such a compiler?
The current mandatory annotation definitions (7.4.15.4.1) will cause problems when IDL specifications are attempted to be reused between profiles applying different requirements concerning annotations (for example a profile with annotations and a profile without annotations or two or more profiles with different sets of annotations).
As the IDL 4 specification has removed the support for the commented form of annotations there is no possibility anymore to declare annotations in a form that has semantic meaning in one profile and does not cause parsing errors in another profile not supporting (these) annotations.
Even with the commented form supported the mandatory specification of annotation definitions for applied annotations would cause similar kind of problems as it is likely that the definitions for the standard set of annotations from one profile would not be available in another profile not supporting those annotations.
Personally I do not see any use for annotation definitions (and in fact I cannot find any commentaries regarding that in the spec) but I would suggest that at the very least IDL compilers should be allowed to ignore any annotations not known to the profile for which the IDL compiler is configured.
Ideally I would like to see a specification without any mandatory annotation definitions leaving it up to the tool supplier to enforce annotation definitions or implement implicit (embedded) definitions.
this section says: // GIOP 1.0 struct LocateRequestHeader_1_0
{ // Renamed LocationRequestHeader unsigned long request_id; sequence <octet> object_key; }; Anonymous types are deprecated so this struct has to be updated
There is currently no specification for fixed-point types in the COM/CORBA mapping. I'm interested in getting this changed: how can we proceed? better still, is this work already under way??
I just noticed that the description of DynValue is totally silent on the
issue of derived valuetypes.
Here's an example to set things up:
// IDL
valuetype A
{ public short s; };
valuetype B
{ public long l; };
struct S
{ A an_a; };
// C++
DynamicAny::DynFactory df = ...;
B *b = ...;
S my_s;
CORBA::Any my_any;
s.an_a = b;
my_any <<= s;
DynamicAny::DynAny_var da = df->create_dyn_any(my_any);
DynamicAny::DynStruct_var ds = DynamicAny::DynStruct::_narrow(da);
ds->seek(0);
da = ds->current_component();
DynamicAny::DynValue_var dv = DynamicAny::DynValue::_narrow(da);
CORBA::TypeCode_var tc = dv->type();
cout << tc->id() << endl;
-----------
Now some questions:
1. What is printed by the above C++ code? "IDL:A:1.0" or "IDL:B:1.0"?
2. If the typecode is for valuetype A, what happens to the members
defined in valuetype B? Seems they must be inaccessable yet still
recoverable if I convert the DynValue back to an any and extract the
value, because I can't truncate a B to an A.
3. If the typecode is for valuetype B, we now have the interesting case
where:
tc->equivalent(ds->type()->member_type(0))
is false. Is this going to confuse programmers or programs? I think it
will, since it means that if I try to insert dv into another DynStruct
via assign() or the like, it will fail, since the TypeCodes are no
longer equivalent.
4. Do the answers change if B is truncatable and the program can find
the TypeCode for B (perhaps via SendingContextRunTime)? How about if it
can't find the TypeCode?
The spec doesn't make it clear what is a valid mix of policies and what
is invalid. For example, should it be legal to set a
RequestPriorityPolicy, MaxHopsPolicy or QueueOrderingPolicy value if the
RoutingPolicy is ROUTE_NONE?
Also, should setting both RequestEndTimePolicy and
RelativeRequestTimeoutPolicy be illegal? Or must the client/server pick
which ever one expires first?
What is a messaging router supposed to do if it receives multiple
requests from a client with more than one type of QueueOrderingPolicy
value? (Is this legal? Is it legal to have more than one QueueOrdering
bit set in a single request?) How can it sort on priority, FIFO, and
deadline simultaneously?
The spec appears silent as to whether valuetypes are allowed to support local interfaces. Table 3-10, for example, says nothing at all about local interfaces.
There's a couple ways to look at this. First, valuetypes are not CORBA objects. Servants for local interfaces are direct CORBA object instances, i.e., the "local" declaration on an interface effectively removes the distinction between a CORBA object and its servant. If a valuetype were used as a servant for a local object, then the valuetype would itself also be a CORBA object. By this analysis, valuetypes should not be allowed to support local interfaces.
Another way to look at it is that the valuetype should just inherit the local interface's operations and attributes without having any subtype/subclass relationship with the base local interface. This would be a rather pointless approach to take, is there would be no possibility of using the valuetype polymorphically with respect to the base local interface.
[..] It is used to indicate the relative amount
of time for which a Request or its corresponding
Reply may be delivered. After this amount of
time, the Request is cancelled (if a response
has not yet been received from the target) or
the Reply is discarded (if the Request had
already been delivered and a Reply returned from
the target) [..]
---------------------------------------------------------
Question:
Does it mean that client ORB just gives up or
does it mean that client tries, in kind of best
effort semantics, to cancel request on server?
If this cancellation fails, how will client user
be informed about this? By a minor code in
thrown Timeout exception?
Is it possible to clarify this?
Fifth bullet near the beginning of this section states:
Incarnations of a particular object may not overlap; that is, incarnate shall not be invoked with a particular ObjectId while, within the same POA, that ObjectId is in use as the ObjectId of an activated object or as the argument of a call to incarnate or etherealize that has not completed.
Unfortunately, I do not see anywhere where the exception to be thrown from activate_object_with_id() for this case is specified. According to this text, if incarnate() is executing for a particular ObjectId, any calls to activate_object_with_id() should be rejected by the POA. This came up in comp.object.corba, where someone posted a question as to why Orbix 2000 throws the ObjectAlreadyActive exception for this case.
The CORBA specification has module SendingContext { //... interface CodeBase
{ //... CORBA::FullValueDescription meta(in CORBA::RepositoryId x); //... }; //... }; but there is no CORBA::FullValueDescription defined in the specification, yet the supplied <SendingContext.idl> file declares module SendingContext { //... interface CodeBase
{ //... CORBA::ValueDef::FullValueDescription meta(in CORBA::RepositoryId x); //... }; //... };
The GIOP specification does not say anything at all about the rules for marshalling ValueBoxes.
I believe the expected format is to marshal ValueBoxes as if they were a normal Value with a single member, and that they follow the normal rules about indirections and chunking. The spec should clearly state this.
BTW I think the twiddle is incomplete because it is not reflected
in the BNF for Identifier. I think it is better if the BNF always
reflects the ultimate specification of a language's lexical
definition. Otherwise compiler writers are apt to miss the
subtleties.
I'll propose some BNF changes if others agree
21.3.9.2 states:
"In the DSI model, since the parameters are first available when the user code calls arguments, receive_request is called from within arguments. It is possible that arguments is not called in the DSI model. The target may call set_exception before calling arguments. The ORB shall guarantee that receive_request is called once, either through arguments or through set_exception."
The problem here, is that the DSI servant has already been invoked at this point, and the DSI implementation will be unaware that the server interceptor may have cancelled the invocation via raising a system exception or ForwardRequest user exception. So the DSI implementation will carry on, creating all sorts of wonderful havoc as it continues to interact with the ServerRequest PO.
Any vendors want to comment on what their PI implementation does now?
Proposed fix:
First, we should define a new system exception minor code that the servant implementation can detect so that it can clean up and get out of the way as expeditiously as possible when raised by arguments or set_exception. Perhaps a minor code for OBJ_ADAPTER? Should there be two minor codes, to distinguish a system exception from ForwardRequest as the reason for cancelling the invocation?
Second, we need some more text either in chapter 8 or 21 that states that any calls by the DSI implementation to ServerRequest::set_result or ServerRequest::set_exception will be ignored (or perhaps reraise the exception defined in the previous paragraph) if ServerRequestInterceptor::receive_request raises an exception.
There is a small issue with the restriction of where a valuetype chunk can end. The spec says
"The data may be split into multiple chunks at arbitrary points except within primitive CDR types, arrays of primitive types, strings, and wstrings, or between the tag and offset of indirections. It is never necessary to end a chunk within one of these types as the length of these types is known before starting to marshal them so they can be added to the length of the currently open chunk."
However, in the case of array of wchar, the length is not known before starting to marshal, since each char (in GIOP 1.2 and 1.3) is marshalled as a (sort-of) sequence of octets. I think it should be legal to end a valuetype chunk in the middle of an array of char.
There is a sentence in t