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 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.

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.

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.

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?

RE: CCM chapters document [orbrev] 99-10-04, section 61.6.2, page 61-45.
The document citation indicates that the integrity of the valuetype –
that is, the received marshalled state – is to be preserved in an
ORB-mediated operation, even if that valuetype cannot be unmarshalled,
either partially (truncated) or at all. If this value is then passed to
another operation, the original marshalled state is to be transmitted.
This preserves the transmitted object in its entirety, regardless of
local implementation concerns. This is obviously necessary for bridges
or event processing, such as through the notification service.

So the question arises, what happens if you have a partial (truncated)
unmarshall and the recipient application changes the local state of the
valuetype through its attributes or local operations? How can/will you
even know the state was changed? Do you ignore the changes and send the
originally received marshalled stream, send only the new valuetype even
though it is a truncation of the original, or "merge" the new values for
the unmarshalled part followed by the original appended data for the
truncated part? Should this third option be possible through an
explicit ORB call – that is, the application is responsible to identify
the change in state to the ORB? I assume that the semantics of
"truncatable" must come to include the understanding that data in the
truncatable portions may not be contextually dependent on the inherited
parent of the valuetype.

As a further question, is there a reason why this semantic
interpretation should not be extended to be a general requirement rather
than only with respect to transmission of anys? My experience has found
that passing anys tends to be expensive and is avoided where it can be.
A more general interpretation permits transmission of a comprehensive
data structure among intermediate agents that only use (unmarshall) the
information they need.

The description for Object::get_policy (in the Core, section 4.3.7.1)
states:

"The get_policy operation returns the policy object of the specified
type (see Policy Object on page 4-32), which applies to this object. It
returns the effective Policy for the object reference. The effective
Policy is the one that would be used if a request were made."

For a policy defined by PI, I don't see anyway for the ORB to implement
this operation correctly, since there isn't any way for it to know how
to properly resolve any client override policies with the policy
information stored in the IOR.

When a invocation is actually in process, the ClientRequestInterceptor
can use the information available in the ClientRequestInfo interface to
get the client override and the IOR policy data and do the correct
resolution before continuing with the request. However,
Object::get_policy() needs to do the same type of thing, but it has no
invocation context to do it in.

I think the same problem also applies to the implementation of
ClientRequestInfo::get_request_policy().

I think we need a new interception point to do this work. Something
like:

local interface PolicyInterceptor

;

local interface PolicyInfo

;

If this turns out to be an acceptable solution, then we should also
change ClientRequestInfo to:

local interface ClientRequestInfo : RequestInfo, PolicyInfo

;

and remove the redundant operations.

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.

Deferred

This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

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?

Deferred

This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

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.

Deferred

This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

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.

Deferred

This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

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??

Deferred

This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

During the interceptor FTF we changed the server-side threading
requirements such that all server-side points run in the same thread
as the ServantManager and servant except receive_request_service_contexts.

We attempted to update 21.4.4.4 "Request Scope vs Thread Scope"
accordingly but knew we screwed the picture and wording up. So we
punted to the RTF.

The main problem with the current wording is that is forces a copy of
of TSC/RSC before the servant manager and then receive_request are
called. This is necessary because 21.4.4.5 item 5 says: "The
receive_request points may modify the RSC, but this no longer affects
the TSC."

The only way to make RSC identical to TSC in receive_request with
respect to reading but also have them be independent with respect to
writing is to make a copy (which could be optimized to copy-on-write,
but why?).

I suggest we just state they are equivalent after
receive_request_service_contexts.

Here is a proposed revision to ptc/00-08-06 along these lines.

Comments?
Harold

21.4.4.4 Request Scope vs Thread Scope

... On the server-side, the request scope PICurrent is attached to
the ServerRequestInfo and follows the request processing. It is
logically equivalent to the thread scope PICurrent after the list of
receive_request_service_contexts interception points are processed.

21.4.4.5 Flow of PICurrent between Scopes

5. The ORB logically makes the RSC equivalent to the server-side TSC
after the receive_request_service_contexts points are processed and
before the servant manager is called. This TSC is within the context
for both the receive_request points, the invocation of the servant
manager, and the invocation of the target operation.

The receive_request points are called. These points have access to the
RSC. Modifying the RSC at this point makes corresponding
modifications on the TSC. Since these points execute in the same
thread as the target operation invocation, these points may modify the
server-side TSC which makes corresponding modifications on the RSC.

6. After the receive_request points are called, control transfers to
the server threads which may also read and write this server-side TSC.
Any modifications to the TSC makes corresponding modifications on the
RSC.

7. <No change>

8. <DELETE THIS ITEM>

9. The send interception points have access to the RSC (and the
equivalent TSC) from which they may populate the reply service context
list. After the invocation result is sent back to the client, the
server-side RSC is logically destroyed.

...

The picture would also need updating, but let's agree on wording first.

Deferred

This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

During the interceptor FTF we changed the server-side threading
requirements such that all server-side points run in the same thread
as the ServantManager and servant except receive_request_service_contexts.

We attempted to update 21.4.4.4 "Request Scope vs Thread Scope"
accordingly but knew we screwed the picture and wording up. So we
punted to the RTF.

The main problem with the current wording is that is forces a copy of
of TSC/RSC before the servant manager and then receive_request are
called. This is necessary because 21.4.4.5 item 5 says: "The
receive_request points may modify the RSC, but this no longer affects
the TSC."

The only way to make RSC identical to TSC in receive_request with
respect to reading but also have them be independent with respect to
writing is to make a copy (which could be optimized to copy-on-write,
but why?).

I suggest we just state they are equivalent after
receive_request_service_contexts.

Here is a proposed revision to ptc/00-08-06 along these lines.

Comments?
Harold

21.4.4.4 Request Scope vs Thread Scope

... On the server-side, the request scope PICurrent is attached to
the ServerRequestInfo and follows the request processing. It is
logically equivalent to the thread scope PICurrent after the list of
receive_request_service_contexts interception points are processed.

21.4.4.5 Flow of PICurrent between Scopes

5. The ORB logically makes the RSC equivalent to the server-side TSC
after the receive_request_service_contexts points are processed and
before the servant manager is called. This TSC is within the context
for both the receive_request points, the invocation of the servant
manager, and the invocation of the target operation.

The receive_request points are called. These points have access to the
RSC. Modifying the RSC at this point makes corresponding
modifications on the TSC. Since these points execute in the same
thread as the target operation invocation, these points may modify the
server-side TSC which makes corresponding modifications on the RSC.

6. After the receive_request points are called, control transfers to
the server threads which may also read and write this server-side TSC.
Any modifications to the TSC makes corresponding modifications on the
RSC.

7. <No change>

8. <DELETE THIS ITEM>

9. The send interception points have access to the RSC (and the
equivalent TSC) from which they may populate the reply service context
list. After the invocation result is sent back to the client, the
server-side RSC is logically destroyed.

...

The picture would also need updating, but let's agree on wording first.

RE: CCM chapters document [orbrev] 99-10-04, section 61.6.2, page 61-45.
The document citation indicates that the integrity of the valuetype –
that is, the received marshalled state – is to be preserved in an
ORB-mediated operation, even if that valuetype cannot be unmarshalled,
either partially (truncated) or at all. If this value is then passed to
another operation, the original marshalled state is to be transmitted.
This preserves the transmitted object in its entirety, regardless of
local implementation concerns. This is obviously necessary for bridges
or event processing, such as through the notification service.

So the question arises, what happens if you have a partial (truncated)
unmarshall and the recipient application changes the local state of the
valuetype through its attributes or local operations? How can/will you
even know the state was changed? Do you ignore the changes and send the
originally received marshalled stream, send only the new valuetype even
though it is a truncation of the original, or "merge" the new values for
the unmarshalled part followed by the original appended data for the
truncated part? Should this third option be possible through an
explicit ORB call – that is, the application is responsible to identify
the change in state to the ORB? I assume that the semantics of
"truncatable" must come to include the understanding that data in the
truncatable portions may not be contextually dependent on the inherited
parent of the valuetype.

As a further question, is there a reason why this semantic
interpretation should not be extended to be a general requirement rather
than only with respect to transmission of anys? My experience has found
that passing anys tends to be expensive and is avoided where it can be.
A more general interpretation permits transmission of a comprehensive
data structure among intermediate agents that only use (unmarshall) the
information they need.

Deferred

This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

The description for Object::get_policy (in the Core, section 4.3.7.1)
states:

"The get_policy operation returns the policy object of the specified
type (see Policy Object on page 4-32), which applies to this object. It
returns the effective Policy for the object reference. The effective
Policy is the one that would be used if a request were made."

For a policy defined by PI, I don't see anyway for the ORB to implement
this operation correctly, since there isn't any way for it to know how
to properly resolve any client override policies with the policy
information stored in the IOR.

When a invocation is actually in process, the ClientRequestInterceptor
can use the information available in the ClientRequestInfo interface to
get the client override and the IOR policy data and do the correct
resolution before continuing with the request. However,
Object::get_policy() needs to do the same type of thing, but it has no
invocation context to do it in.

I think the same problem also applies to the implementation of
ClientRequestInfo::get_request_policy().

I think we need a new interception point to do this work. Something
like:

local interface PolicyInterceptor

;

local interface PolicyInfo

;

If this turns out to be an acceptable solution, then we should also
change ClientRequestInfo to:

local interface ClientRequestInfo : RequestInfo, PolicyInfo

;

and remove the redundant operations.

Deferred

This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

On page 22-6, we say for SYNC_WITH_SERVER:

For a server using a POA, the reply would be sent after invoking
any ServantManager, but before delivering the request to the target
Servant.

What's the motivation for this? Why wait that long? The ServantManager
may still fail to return a servant for the request, meaning that
the ORB might as well acknowledge the request before the ServantManager is
called without losing anything.

Also, as specified, the receiving ORB has to first run any adapter
activators. Again, there doesn't seem any point in waiting this long.
Why can't the receiving ORB simply acknowledge the request as soon as
it has read the request header off the wire?

withdrawn by submitter

Incorrect example for recursive definitions which can span multiple levels. I and my IDL compiler are missing an identifier in the following example union for the last struct member.

union Bar; // Forward declaration typedef sequence<Bar> BarSeq; union Bar switch(long) { // Define forward-declared union case 0: long l_mem; case 1: struct Foo

?identifier missing?; };

This has already been fixed in the previous RTF see orbrev/2001-03-01

>From CORBA 2.4, Table 4-3: TRANSIENT minor code 1 is described as:

"Request discarded due to resource exhaustion in POA."

However, section 11.3.2.1 states that minor code 1 is used when the
POAManager is in the DISCARDING state.

I think it would be better to reword this description as:

"Request discarded because POAManager is in DISCARDING state (e.g.
server lacks resources to complete request.)"

Make it so

Following statement in CORBA V2.3 (06/1999),
P10-39, Chapter 10.6.1, OMG IDL Format concerning
the OMG IDL format for Repository IDs:

>> The RepositoryId consists of three components, separated by
colons, (":")

The first component is the format name, "IDL."

The second component is a list of identifiers, separated by
"/" characters.

These identifiers are arbitrarily long sequences of alpha-
betic, digit, underscore ("_"), hyphen ("-"), and period (".")
characters. Typically, the first identifier is a unique prefix,
and the rest are OMG IDL Identifiers that make up the scoped
name of the definition. <<

There are two issues here:

• Firstly I propose to change >>"IDL."<< into >>"IDL".<<
• Furthermore, I propose be more specific on the definition
  of the Repository Id. The above definition does not
  exclude a RepositoryId in the following style (which
  in my opinion does not make sense and effects inter-
  operability between ORBs): "IDL:/A/B:1.0"
  A regular expression could clarifiy this issue:

Incorporate changes and close issue.

The semantics for local interfaces states:

A valuetype may support a local interface.

This brings up two questions.
1. Can it support multiple? In addition to a unconstrained non abstract
interface?
2. Does it then become a local type (I think not, I think it becomes a
local type only when it contains state that is a local type)

No Data Available

given the a DynUnion value, I want to find out whether the discriminator
currently indicates the default case. For example:

union u switch (long)

;

For this union, I want to know whether the default member is active, that is,
whether the discriminator has a value other than 0, 1, or 2.

Finding out whether the discriminator indicates the default case is currently
rather difficult. I have to:

1) get the union type code
2) collect the values of all the explicit case labels from
the type code
3) check if the discriminator currently has a value that is not
one of the explicit case labels values

It would be much nicer to add the following to DynUnion:

interface DynUnion : DynAny

;

The is_set_to_default_case operation returns true if a union has
an explicit default label and the discriminator value does not
match any of the union's other case labels.

Add the is_set_to_default_member function with the functionality as described for is_set_to_default_

In the CORBA 2.4 spec, chapter 10, the definition of #pragma ID has
been modified so that later re-declarations of the same ID for a type
are permitted. Before, it was explicitly an error to use #pragma ID
for a type more than once, even if the same IDs were given.

The section of #pragma version has not been updated. This means that
handling of the two similar pragmas is now inconsistent:

interface A {};
#pragma ID A "LOCAL:foo"
#pragma ID A "LOCAL:foo" // OK in 2.4, error in 2.3

interface B {};
#pragma version B 3.4
#pragma version B 3.4 // Error in 2.4 and 2.3

Should #pragma version be updated to be consistent with #pragma ID?

Incorporate changes and close issue

Consider a servant for a persistent object that sits in front of a database.
Assume a simple implementation model, using RETAIN and
USE_ACTIVE_OBJECT_MAP_ONLY.

We have n CORBA objects with n servants, and each servant implements
its operations by reading/writing through to the persistent store, possibly
also caching some state and maintaining other resources, such as database
connections or memory buffers.

I want to implement a life cycle destroy() operation. In the body of
destroy, I have to write something like:

void
Foo_impl::
destroy() throw(CORBA::SystemException)

The problem is that the servant can't simply blow things away at that
point because there may be other operations running concurrently in the
same servant, and those operations would get awfully surprised if their
state suddenly disappeared.

So, I delay reclaiming resources and deleting the database record until
the servant becomes idle. In C++, that's no problem. Eventually, the
servant's AOM entry disappears and (at least if I use reference-counted
servants) that triggers the destructor of the servant, and I can
clean up in the destructor.

However, it appears that this doesn't work for other languages because they
may not have destructors or, like Java, make no guarantees about when
the destructor will be called.

The problem is that there is no way for me to find out at what
point the servant becomes idle, so that I could clean up.

I think we need a callback from the ORB to the server application code that
notifies the server when a servant finally becomes idle. Otherwise, it is
pretty much impossible to implement life cycle support in languages other
than C++, especially for threaded servers.

Close no change.

The format of the "hash code" element of an RMI Hashed Format repid
needs to be clarified. Section 10.6.2 gives the algorithm for computing
the 64-bit number to be used as the hash code, but does not specify the
on-the-wire format for this number. In contrast, the spec explicitly
states that the 64-bit number representing the SUID is transcribed as
a 16-digit upper-case hex string.

Clarify as suggested below

In 99-07-01 there was a extention of the atribute definition to enable users
to define specific exceptions on GET/SET operations. This extension has
disappear from 99-10-04. What is the reason for it? This extension seems to
be quite usefull in particular if you consider component configuration
phase.

The attribute changes are contained in the core chapter ptc/99-10-03.

In 99-10-04 chapter 62.4.1.4 (The Event Interface) in the paragraph
describing obtain_channel() and listen() the name passed to these methods
are supposed to be an INS name. Where do we get them from?

It seems to me that it should be the port name that should be passed and the
container job would be to link it with an INS name (that it gets through
container specific configuration) and then get the corresponding Admin
interface.

If this is what is intended we might want to make it more clear in the text.

Same as issue 3937.

I have an interoperability question regarding the
corbaname URL in the CORBA 2.4.2 specification and would appreciate
clarification.

In 13.6.7.3, it states that for a corbaloc URL which
uses IIOP, if the port number of the endpoint is
not specified, then the IIOP profile should default
to port 2809 which is specified by IANA as the corbaloc
port.
eg.
corbaloc:iiop:myhost.com/SomeKey

In 13.6.7.5, the corbaname URL is described.
If a corbaname URL is specified for IIOP, but the port
number is omitted, should the ORB assume that the
root naming context will be on port 2809 of the host
specified?

eg.
corbaname:iiop:myhost.com:3000#path/obj

will look for the root naming context on port
3000 of myhost.com.

eg.
corbaname:iiop:myhost.com#path/obj

Should this look to port 2809 for the root
naming context?

see above

In orbrev/01-03-01:

Production rule two at the end of this sections has a comment that it
should include all IDL types, but in actuality is missing "long long",
unsigned long long" and "long double".

Suggest we add these to the production rule in question.

No Data Available

When chunking and fragmenting, it is possible for a chunk length to be
inserted between the indirection tag and indirection offset.
Implementations must be careful to compute the indirection offset
correctly both when writing and reading to avoid errors.

For interoperability, we should elminate this possibility. From an
implementation point of view, the code for handling this special case
should already be there. Please see the original message (see
attachment) for a detailed description of the problem scenario and two
implementation possibilities.

Proposed resolution:

Elminate the possibility of chunk lengths between indirection tag and
indirection offset by changing the following paragraph in CORBA formal
00-11-03 15.3.4.6.

see below

In formal 00-11-03 10.6.2 in the discussion of the serial version UID in
the RMI hashed format, the spec defines the repository ID format as

RMI: <class name> : <hash code> [ : <serialization version UID> ]

and says

"If the actual serialization version UID for the Java class differs from
the hash code, a colon and the actual serialization version UID
(transcribed as a 16 digit upper-case hex string) shall be appended to
the RepositoryId after the hash code."

The Java to IDL spec ptc-00-01-06 1.3.5.7 says

"The syntax of the repository ID is the standard OMG RMI Hashed format,
with an initial “RMI:” followed by the Java class name, followed by a
hash code string, followed optionally by a serialization version UID
string."

Questions:

1) Is it legal to include the serial version UID in the repository ID
even when it is equal to the hash code? (Alternatively: Is it legal
for an ORB to throw an exception/fail if the hash code and serial
version UID in the repository Id are the same?)

2) If it is not legal to include the serial Version UID in the
repository ID when equal to the hash code, what should an ORB do?

Discussion:

Other than it not harming anything to include the SUID, there are rare
cases that the same Java class compiled with different compilers can
result in different default serial version UIDs, so it would be wise to
explicitly specify the serialVersionUID field even in the first version
of a class. If it is legal to always include the serial version UID
part of the repository ID, ORBs with classes from two different
compilers would still be able to interoperate.

see below

The specification does not say whether extra data after the invocation
parameters in a Request or Reply body is ignored or considered an
error. For interoperability purposes, the spec should require one or
the other.

see below

Let us assume that the server has sent a few reply fragments. But before sending all the reply
fragments, an exception occurs (say while marshalling the response).
What does the server and the client (which has already seen reply fragments) do ?

Just to note, notice that if the same problem happens while the client is in the midst of sending
request fragments, the client can choose to send a CancelRequest message to intimate the server.

Since there are various possible behaviours for the client and server, the GIOP specification needs
to clarify the standard behaviour, in order for different implementations to remain interoperable.

One possible behaviour :

The server could send back a seperate response (containing the exception with
CompletionStatus.COMPLETED_YES). The client on receipt of the new reply, and noticing the fact that
another reply with the same requestId is pending, could discard the pending reply and process the
latest reply.

Another behaviour :

The client could simply timeout the request and discard any new reply streams (with the same
requestId), and raise an exception with CompletionStatus.COMPLETED_MAYBE.

This issue is resolved by the resolution to issue 4273.

The Components::Navigation interface that is implemented by all
components provides introspection ("generic navigation") capabilities.
There are lots of use cases for introspection, so I wonder why there
is introspection for facets, but not for receptacles or event ports.
I suggest to add such introspection capabilities. All introspection
features should be alike as much as possible for ease of usage.

see below

. I don't
think OMG specifications should use a single term in two distinctly
different ways. The text of the issue starts with the sentence,
"the Components spec and valuetype spec treat "supports" exactly
*OPPOSITE* in semantics regarding widening/narrowing." and continues
for about 3 or 4 paragraphs. Ed's comment should go in there too.

rejected

Looking at ptc/99-10-04, it is not clear to me which parts of this
document are intended as normative.

For example, the introduction to chapter 66, "Component Container
Architecture", states that the presented design "is not the only
possible design choice." Consequently, it appears that the entire
chapter 66 is not intended as normative. However, looking at the
actual text, a reader might be easily confused into taking aspects of
the design as normative.

While this text was helpful in the submission to give readers an
insight how the submitters might design their implementations, it
should be removed from the specification, to really give implementors
the freedom of design choice that was apparently intended with the
submission.

see below

Section 8.3.1 says "The signatures of the CORBA component operations are mapped to signatures of EJB remote interface methods following the IDL to Java mapping rules."

As far as I can see, this only works if the IDL signature has no out or inout parameters. The Holder classes for out and inout parameters cannot be used in an EJB interface signature because they need not be Serializable, which breaks the rules for an RMI compliant class. Even if they could the EJB stubs and skeletons would not implement their special return value behavior without modifications to the EJB spec.

Someone please tell me I've missed something!

see below

The CCM exceptions mapped from EJB standard exceptions need to be defined
explicitly in OMG IDL. The resolution to issue 3182 introduces new CCM
standard exceptions Components::CreateFailure, Components::FinderFailure
and Components::RemoveFailure but it does not define them explicitly.

see below

The use of the state keyword in the Components::Enumeration valuetype,
introduced by issue 3099 and extended in issue 3418, is not correct
syntactically. Also, anonymous sequences have been deprecated, so the
definition of the Components::Enumeration state is incorrect in this sense
as well.

see below

The CCM MOF IR draft (ptc/99-10-05) uses UML to denote the MOF model
of the IR. Without missing elaboration, it is not possible to mentally
construct the metamodel. For example, the enumeration, primitive, and
unchangeable stereotypes don't have a well-defined relationship to MOF
concepts. It seems that the MOF chapter should use the UML MOF profile
(ad/01-02-29). In addition, it would be desirable if a normative XML
document that defines the metamodel (following the MOF DTD) is
provided.

see below

I am somewhat surprised over the ExtendedIR interface in 00-11-01.
I am very aware of problems with extensibility in the Interface Repo-
sitory. In the past, a lot of problems have been caused because modi-
fications like InterfaceDef::is_abstract have been worked in and out.
We certainly desperately need a backwards-compatible Interface Repo-
sitory.

This is unachievable with version pragmas, because then a client's
is_a inquiries with "old" Repository Ids will fail, and the client
will refuse to talk any further.

Backward compatibility is instead achieved by not changing data types
(such as InterfaceDescription) and by not changing the signature of
existing attributes and operations.

Adding new types that are used by new operations on existing interfaces
does not break compatibility, because the client will simply be unaware
that there are more operations than it knows of (such as describe_inter-
face_2_3).

Whether changing interfaces sensible is debatable, surely it's more
consistent to use derived interfaces instead – this has the least im-
pact on compatiblity.

In that light, I wonder whether the proposal in 00-11-01 gets us any
further. It adds more fixed interfaces in another module, and this new
ExtendedIR module is just as static as the old ones have been. If any
further changes were necessary, backwards-incompatible changes were
just as necessary.

The proposal in 00-11-01 also adds a lot of unnecessary verbose baggage
with its use of "extended" everywhere, and its usage of multiple inheri-
tance from the original interfaces is confusing.

Yet there is one item from 00-11-01 that I like much better than the
proposal in 99-10-03, and that is the usage of AbstractInterfaceDef and
LocalInterfaceDef. I think that's the way to go.

Therefore, I tend to vote against issue 3233 and its proposed resolution
in 00-11-01.

Rather, I propose to go back to the original version instead, and

• to add AbstractInterfaceDef, LocalInterfaceDef and the related
  container operations
• to add an AttributeWithExceptionsDef and InterfaceDef::create_
  attribute_with_exceptions and ValueDef::* operations.

Whether the Interface Repository should be moved to a different module
should be a separate discussion. I support the idea, but I don't think
that the implementation should be forced to offer access to the IFR
using both the CORBA:: and IR:: modules.
Note that vendors could still offer the old interfaces in their imple-
mentation.

see below

The CCM standard indicates that all CCM Event functions will delegate to
the container. Chapter 7 of the CCM Volume 1 further dictates the
interface the container will provide to the component, called
Components::Notification::Event, referred to as the "Event Interface"
hereafter. This interface contains many problems and does not address
all the required functionality. The problems are listed below:<p>

• The create_channel() method returns an EventConsumerBase for the
  publisher to use to publish events to the channel. It is not possible
  for the Event Interface to construct a concrete EventConsumerBase,
  specifically the interface defined as
  <publishing_component>EventConsumers::
  <event_type>Consumer (per section 5.6.6 and 5.6.7 giving the
  publisher and emitter IDL expansion). The Event::obtain_channel()
  method has the same problem
• The subscribe() method implies that the container supplying events
  will hold the supplier proxy that will be used to send events to the
  subscriber’s EventConsumerBase. This is an inefficient model. Also,
  this model is in direct conflict with the listen() method, which
  supports a more efficient model (see next bullet).
• The standard does not provide any documentation on when a consumer
  would call the listen() method. The standard also does not provide a
  means for the consumer’s component to realise the "csmr_name", the
  name used to find the ConsumerAdmin from the Naming Service [see
  possibly related issue #3940]. Nor does the standard indicate when
  the ConsumerAdmin would have ever been added to the Naming Service.
  It might be possible that this would work for emitters, but it does
  not work for publishers (the standard dictates that a consumer cannot
  distinguish between being connected to an emitter or a publisher).
  This method does imply that the consuming component will have a proxy
  local to its container, separate from the publishing component’s
  container (contradictory to the subscribe() method, see previous
  bullet).
• The push() method does not provide a means to indicate which channel
  the event should be pushed to see possibly related issue #3928.<p>

The Event Interface is a local interface ­ that is, the client will
never see this interface, and so it is possible to hide the use of this
interface inside the generated code and thus replace the interface.
Internally we have added a PortManager interface to be used in place of
the Event Interface. This interface provides better management of the
Event Channels and it also manages receptacle connections. Two
interfaces will derive from the PortManager, a TransientPortManager and
a PersistentPortManager. These two derived interfaces will permit
connections between components to be managed as defined by the type of
the container. Where meaningful, this permits the port connections to be
made persistent as part of the overall state so that connections
(specifically, notification channels) can be more reliably and robustly
managed. The CCM2Context::get_event() operation is replaced by
get_port_manager()

See issue 3937. rejected

The definition of homes does not permit interface inheritance. It
appears this is an oversight as the omission seems unreasonable and
counter-intuitive, especially since homes must follow a parallel
derivation hierarchy with their component types. I have found cases in
which a home would expose the same interface as its component in which
the home subsequently delegates to a specific component instance (even a
persistent instance) however selected. (The component instance may or
may not be hidden from the client.) Interfaces are a perfect mechanism
whereby the operational signatures could be standardized, thus
eliminating potential errors caused by changing one but not the other.
This could be accomplished using a supports clause in the inheritance
specification similar to that of valuetypes.

see below

See the CORBA Components specification, orbos/99-07-01, chapters 5, 6,
7, and 9. The semantics, life cycle, and mechanisms behind components,
facets, "regular" objects, and their related object references is weakly
specified. In particular, it is not clear how a component interacts
with a container to generate an object reference to a facet, especially
a facet in a secondary segment. The description of component
identifiers indicates that the component object id, the facet number,
and the segment number are used to generate the facet's object reference
(or perhaps only the ObjectId), but the sequence of operations is not
given. It appears that not all the necessary methods have been formally
specified, nor are the code generation examples adequate for this
siutation.

Consider the following IDL:

interface A {};
component C

;

What is the life-cycle of the A object returned as the provided facet?
Is it limited to the life-cycle of the component? Is the member
operation returning an object of the same type as a provided facet
permitted? Should this return the same object as the facet? If not, is
the life-cycle of this extra object limited to the life-cycle of the
component? Should such objects be considered facets, even if not
explicitly declared such (which, please note, provides the equivalent of
the deprecated "provides multiple" capability)? What information needs
to be encoded in its object reference, especially for component
dependency? How will the context for this be established, and are any
additional interfaces or operations required to accomplish this?

rejected

The CCM does not describe the behavior of the system in case of various fault situations. In particular, this issue only concerns itself with the recovery mechanisms of event subscriptions or facet receptacles that were automatically established through an assembly. While it is outside the scope of the CCM to describe general fault behavior, it is felt that recovery mechanisms (or their absence) should be explicitly identified for connections automatically built between ports. Otherwise, why go to the trouble of building them, since error detection and recovery wrappers would be needed around any use of them?

The following scenario highlights the various situations. It assumes that the components are deployed in separate processes on different platforms so that one of the two components remains operational despite failure or inaccessibility of the other. The scenario primarily deals with the recovery of an interface provided by Component X and used by Component Y. Appropriate questions related to event channels are also given where applicable. Event channels are themselves more difficult because the notification services adds yet another object to the set that may fail during the scenario.

Scenario: Component X declares that it provides an interface A. Likewise, Component Y declares that it uses interface A. (Or, X emits or publishes event A to which Y subscribes.) Instances of the components are combined through an assembly. Now, the assembly description indicates that a connection is to be built between X and Y. That is, the descriptor defines connections in which a connection element defines the association. Said element’s providesport acquires X’s facet A and assigns that through the usesport to Y’s interface receptacle. (For events, read these as emitsport or publishesport and subscribesport.)

The following questions arise:

When does the connection take place, during assembly construction or on reference to the port’s receptacle inside Y? That is, is this immediate or lazy initialization? When are event channels created or attached? Can the producer delay creation or attachment until a push() operation? Can the consumer accomplish the creation? Can an m:n emitter to consumer notification matrix be built? (The specification is unclear on this.)
What happens if the interface reference to A cannot be acquired because (1) X has failed or is inaccessible, (2) X fails during the get operation, or (3) X returns a nil reference?
What happens during run-time when Y invokes an operation on A and:
The application server process containing X has terminated (COMM_FAILURE returned)?
Derived valuetype arguments cannot be marshalled (MARSHALL/BAD_PARAM returned)?
The underlying object supporting A in X has been deleted (INV_OBJREF returned)?
An unexpected application error occurs (UNKNOWN returned)?
With respect to error detection and recovery:
How does one indicate the set of objects that can detect the error? Possible objects are Y, Y’s home, Y’s container, X’s container, X’s home, the assembly, an independent third party.
How does one indicate the set of objects that can recover the error?
How does one indicate whether the error should be detected?
How does one indicate whether recovery should be attempted?
How does one indicate the recovery strategy, especially if there are several objects that can recover the error?
If the strategy has multiple fallback conditions, should this logic be placed into a single object or should it be given as a precedence-ordered list?
Where should this information be specified: IDL, CIDL, or XML?
What are the implications when the components have different type and container semantics?
Let component X be transient and component Y be an entity. If component X fails, can a new X be safely created for its corresponding Y?
Assume a new X was created and the old X still exists but became inaccessible. Can the old X be detected and one of the X’s be deleted [dismissed] after the old X is again accessible?
Assume a request to X completes successfully in X but fails during the reply to Y. Can the operation be retried or the previous results retransmitted, either on the old X after recovery or on a new X?
In these questions, what happens if X is an entity and Y is transient?
In these questions, what happens if Y aborts rather than X?

Ideally, it would be nice if either the IDL extensions or the CIDL constructions permitted specification of an error recovery wrapper around access to a receptacle (or event channel). This could actually work as a general mechanism for any component and not just components grouped in an assembly. The wrapper would be a specialized object implemented specifically in the context of the component or assembly that provided the desired error detection and recovery behavior. It would be a proxy similar to a stub: it would have the same interface as the target object to which it delegates. Errors would be caught (as described) and recovered automatically, if possible. This includes the initial reference to an object, which would now be built or acquired dynamically at run-time rather than semi-statically at assembly instantiation. Multiple inheritance, in languages that support it, would be very useful in standardizing proxy behavior. The component DTD could be used to specify desirable run-time operation and associated characteristics.

rejected

The third part of the adopted CCM submission (orbos/99-07-03)
moves all the create_..._tc operations from the ORB interface
to a new PIDL interface, CORBA::TypeCodeFactory.

This change breaks source-compatibility: source code that creates
typecodes with a pre-CORBA 3.0 ORB will need to be updated to use
a CORBA 3.0 ORB with such a TypeCodeFactory interface.

And there is no clear benefit from this update:

• ORB is still PIDL – it even creates an additional PIDL
  interface.
• type code kinds are not more extensible (TCKind is still an
  enum)

I suggest to undo this update, i.e. keep the create_..._tc
operations on the CORBA::ORB interface.

see below

While reviewing the ComponentIR interfaces in 00-11-01, I have found
some problems with it. (These are unrelated to the current discussion
about the Interface Repository itself.)

Many interfaces inherit Contained::describe(), which is supposed to
return information about the element. In the basic IFR, this data is
designed to contain all possible information about that type. This
is very convenient, since then a map mapping RepositoryIds to
Contained::Description contains all of the IFR's information.

By referring to InterfaceDefs rather than RepositoryIds, the client
will need to store that association elsewhere, or repeatedly invoke
the Interface Repository.

Suggested resolution:

• In ProvidesDescription, replace
  InterfaceDef interface_type
  with
  RepositoryId interface_type

• Ditto for UsesDescription

• In EventDescription, replace
  ValueDef event
  with
  RepositoryId event

• In ComponentDescription, replace
  ProvidesDefSeq provides_interfaces
  UsesDefSeq uses_interfaces
  EmitsDefSeq emits_events
  PublishesDefSeq publishes_events
  ConsumesDefSeq consumes_events
  with
  ProvidesDescriptionSeq provides_interfaces
  UsesDescriptionSeq uses_interfaces
  EmitsDescriptionSeq emits_events
  PublishesDescriptionSeq publishes_events
  ConsumesDescriptionSeq consumes_events

• In PrimaryKeyDescription, replace
  ValueDef primary_key
  with
  RepositoryId primary_key

• In HomeDescription, replace
  PrimaryKeyDef primary_key_def
  FactoryDefSeq factories
  FinderDefSeq finders
  with
  PrimaryKeyDescription primary_key
  OpDescriptionSeq factories
  OpDescriptionSeq finders

Next, all parts of the "basic" Interface Repository are mutable, but
most attributes of the Components interfaces are declared as readonly.
I propose to remove the readonly modifier from

• ProvidesDef::interface_type
• UsesDef::interface_type
• UsesDef::is_multiple
• EventDef::event
• ComponentDef::supported_interfaces
• ComponentDef::base_component
• ComponentDef::provides_interfaces
• ComponentDef::uses_interfaces
• ComponentDef::emits_events
• ComponentDef::publishes_events
• ComponentDef::consumes_events
• PrimaryKeyDef::primary_key
• HomeDef::base_home
• HomeDef::managed_component
• HomeDef::primary_key
• HomeDef::factories
• HomeDef::finders

Last but not least, there seems to be some confusion about Primary Keys.
When a Home is created with Repository::create_home, a ValueDef should
be passed, while the terminology seems to dictate a PrimaryKeyDef instead.
You can get a PrimaryKeyDef using HomeDef::create_primary_key, but that
would be a chicken-egg scenario.

Proposed resolution:

• Change the ValueDef in Repository::create_home to PrimaryKeyDef
• Move the create_primary_key() operation from HomeDef to Repository

see below

I have noticed that assemblies do not follow the composition pattern.
Thus, assemblies cannot themselves be used as building blocks for other
assemblies. I think part of this comes from the fact that installation
and management of assemblies is mostly "magic" done behind the scenes by
various installation and support utilities. In order to "reuse" an
existing assembly, one must copy an existing assembly definition (I
guess constructed completely by hand) to a new definition, which must
then be tailored to incorporate the new strategy and pieces. This seems
counter-intuitive, besides being manually intensive, for if an assembly
does useful work, why would I want to expose its internal details just
to take advantage of that usefulness? As pointed out by Mr. Dubois in
issue 3939, because all of that "magic" is not specified by various
formal interfaces, it is highly likely approaching certainty that
assemblies will only work for the particular vendor on which they were
built. Since I believe the intention was to promote interoperability in
general and as much code automation as possible for components in
particular, it would seem that we want to restrict the "magic" by taking
the formalisms behind assemblies to another level.<p>

I suggest that, just as a <i>composition</i> exists to tie a component,
its home, and various configuration properties together, we can create
for the CIDL grammar productions for an <i>assembly</i> to tie multiple
compositions together. Subsequently, an assembly could be treated as a
composition, to be used by other assemblies, only exposing selected
facets or events from its constituent entities. I think there are a
number of advantages to this approach: (1) It solves certain semantic
ambiguities with assemblies, for instance whether facets, receptacles,
and events are private or public to the assembly. (2) The assembly
implementation, its XML, and its relation to its constituents and home,
can be generated automatically from the CIDL description [we have been
working on this extensively]. Our approach is to use an assembly
exactly like a composition, as the realization of a component and home
definition. Our research efforts imply that all of the assembly
component and home code can be automatically generated - no user
tailoring will be needed. (3) Because the assembly now acts as a
component (composition), it can be reused by other assemblies without
knowledge of its internal structure. (4) Activation of an assembly
appears the same as for any other component; it merely requires formal
specification of previously undefined interfaces to accomplish it, thus
promoting portability and interoperability. (5) The assembly
"deployment magic" becomes exposed through the interfaces above, thus
removing several of the deployment tools and servers/services identified
in the specification. The only real drawbacks I see are the complexity of the assembly
productions (we can really get out of control with this) and that
assemblies now have an actual code base rather than being "magical
creatures" managed by the deployment tools. I guess these are both
two-edged swords. There might be a run-time footprint change for all of
these extra interfaces, but those had to be lying around in other places
anyway.

rejected

The semantics of components of a particular type (session, entity)
residing in a compatible container type that access components of a
different type residing in a corresponding but different compatible
container type are unclear. Are there any expected or preferred
combinations? Are any disallowed or discouraged? See, for example, the
discussion under issue 4025 on automated recovery. In his replies, Mr.
Dubois seems to assume that entity components create transient (service
or session) components but not the reverse. In the telecommunications
domain, however, a session object may share access to an entity, and
then create additional entities based on external events, even though
the session itself is not persistent. Could someone please articulate
the possibilities and their utility (or lack thereof)?

rejected

See the CORBA Components Model specification, orbos/99-07-01, paragraph
10.6.2.52, page 10-365. See also the DTD appendices document, orbos/99-08-05.

The title of this paragraph heading is incorrect. The element is "usesport",
not "usingcomponent". It has occasionally been hard to find the description
because of this textual error.

see below

In ptc/99-10-04 on page 15 the grammar rule of home_executor_body in chapter
60.7 "Home Executor Definition" contains bars implying alternatives. These
bars have to be removed to match the subsequent description.

see below

As the CCM spec is not giving any mean (or very little) to fill in the
filterable body part, no services are provided for a component to set its
event filters when sending or receiving events.

This seems to be a very usefull service to me for application such as:

• limiting the number of events emitted by a component based on a config
  parameter (like messages with priority > config value can go out, other are
  discarded. when the config value change at runtime the filter could also
  change.
• filtering events received from a notification channel.

I agree that these 2 function could be achieve by user code in the component
but it means that unecessary events are passed between components and the
netwok load and CPU load is higher than necessary.

I guess the point I am trying to make is that using the notification service
without using filters and/or filterable body doesn't seem to make a lot of
sense.

What is the intend of the sepc on this issue?

See issue 3938. rejected

See the CORBA Component Specification, orbos/99-07-01, and Persistent
State Service issue #4074. Is there any reason why homes cannot support
(manage) multiple component types? This seems like a perfect case for
polymorphism; the only time you really need a new home type is when you
change the behavior or have some other incompatibility. Is it possible
to do instances of homes, one per component type (perhaps instances of
components acting as managers for other components)? I simply do not
understand why these are one-to-one with parallel but distinct
derivations. I realize the requirements were to maximize code
generation, but I don't see that this is a conflict.

rejected

In a complex distributed environment, the implementation of highly
available and highly reliable services requires redundant placement of
software components in all their manifestations. Assemblies provide a
nice, convenient way of specifying the deployment and activation of
components and the connections that relate them for a particular
purpose. Now, for various reasons and Fault Tolerant CORBA
notwithstanding, in corporate reality this sequence and specification
will occur in multiple places in basically identical fashion. About the
only thing that changes are the host names and their network addresses;
everything else from the hardware configuration to the size of the disk
drives and file systems is (and inherently must be) exactly the same
among all deployments. This, for example, is one technique to support
geographic site failover.

My question is, has anyone thought of a two or more stage XML process,
one in which the package or assembly composition and deployment XML is
specified as a template or configurable, parameterized entity, and
another where the parameters have been substituted for "finalization"?
This can occur at two distinct points in the life-cycle: one set of
substitutions occurring when an artifact is deployed (installed?) on the
various computer systems involved, and another when the home [and
possibly individual instances] of the artifacts are activated
(instantiated?) to run on those computer systems. My work in the
telecom and defense industries has show that deployment of anything is
rarely a singleton event; there are always redundancies, replications,
and backups to take into account. Templates seem to provide a nice
solution to all of the manual editing required.

rejected

Is there any reason to name the context interface for extended session
components as Session2Context in module Components::Extended? Why not simply
SessionContext like in the Basic module?

see below

How to activate servants by only using the Session2Context interface from
the Extended module? It only offers operations to create references like
create_ref() and create_ref_from_id() similar to those from the POA but no
means to activate servants are available in the whole container API!

see below

The CCM spec seems to have make the choice to prevent the component
implementor to fill in the filterable body part of a structured event sent
to the a notification channel.

What are the reasons of this choice?

2 remarks:

• The filtrable body part of a structured event seems to be the most usefull
  part of the event. Not using it (or leaving it to the container to fill in
  from obscure sources) doesn't seem to make a lot of sense.
• Other standard bodies (like T1M1.5) are using the filterable body part of
  the event and are making the remainder of the boby (where the EventBase
  derived value type should be put) optional and unnecessary.

Any comment/explanation of the choice is welcome.

See issue 3938. rejected

I have the following question (problem). The Corba Component Model Spec
(volume 1) defines the following :
module CORBA_3 {
module Components {
interface Events

;
...
module Events

;
};
};

So the word 'Events' is used for defining an interface and a module!! Is
this correct IDL, because ther JavaORB idl-compiler nor the ORBACUS
idl-compiler is able to compile such idl.

see below

I was researching the CCM Event Corba 3 to Corba 2.3 mappings in
chapter 5 of Volume I, and found that the resulting interfaces did not
permit a consumer to subscribe to a publisher because the interface
type returned by the get_consumer_<name>() does not match the
subscribe_<name)() parameter. I am not sure if I made a mistake when
mapping the 3.0 to 2.3 idl or if it is a problem in the standard. I
also provide an alternative that might work, though I'm sure it will
need some work.

Resolved by reference/clarification to 3746

in 99-08-05 the componentassembly DTD has a typo in the "connections"
element definition. "connecthome" should be spelled "connecthomes"

<!ELEMENT connections
( connectinterface

see below

The description of the life cycle and system dynamics of the various
objects that contribute to component deployment and execution is
incomplete. From an implementation perspective, there are many run-time
objects involved that contribute to, or are required for, the overall
operation of a component. But the CCM does not adequately show the
interrelationships among such objects. Even the most rudimentary
implementation depends on the assumptions hidden behind these
interrelationships.

The following questions need to be addressed in order to build a
portable implementation:

1. Deployment support services:

• What is the life cycle of the support services needed to create an
  Assembly object?
• Do these already need to be executing in, known to, or exposed by one
  or more servers?
• How are these services contacted in a dynamic environment?
• Is this structure equivalent to the TINA DPE concepts?
• What is the life cycle of the Assembly object itself?
• When and how is an Assembly object deleted?

2. Application servers, containers, homes, components:

• What is the exact life cycle of these various objects?
• The specification identifies how component instances are created. How
  are they deleted?
• When and how is a home removed from a container?
• When and how is a container removed from an application server?
• When and how is an application server terminated?

3. Related or referenced objects:

• What is the life cycle of event channels?
• Does the life cycle of objects vary if they are "private" to an
  assembly?
• When and how are event subscriptions released from their publisher or
  emitter?
• When and how are objects "registered" with the naming service or
  trader unregistered?

A full and representative life cycle description of the run-time objects
denoted above is necessary to understand the dynamic system model and
its inherent limitations. This will be critical for systems that must
exhibit very high reliability and availability. There appear to be many
assumptions, particularly with respect to the deployment tools, that
affect recovery operations from fault conditions. These must all be made
explicit. Thus, the CCM description should include a comprehensive state
transition model. This may be documented as cooperating or nested state
machines for the various pieces.

see below

The CCM describes the services available for a basic container as being
one of two sets: security, transactions, and naming or security,
transactions, and persistence. Could someone please describe the exact
services available to basic containers and the particular semantics for
each? Are these differences related to one set for the component home
and the second set for the instance?

rejected

See the CORBA Components Model specification, orbos/99-07-01, section
5.6, pages 5-84 through 5-89, approximately.
Could someone clarify the push() and push_event() operations, their
purposes, and their interaction, if any. There is no description
whatsoever of the relationship between the push() and push_event()
operations, even though push_event() is declared in the
inherited Components::EventConsumerBase. The producing component
invokes its push() operation, which then performs any peculiar
formatting to the event before transmission to the underlying channel
through its container. It is unclear when, if ever, the push_event()
operation will be invoked. A text search of the document reveals the
operation appears only in the interface definition and its immediate
descriptive paragraphs.

Would a better model be to use push_event() as the interface to and from
the container? (Perhaps this should be independent operations,
produce_event() and consume_event()?) On the producer side, let push()
perform any component specific formatting of the event before passing
the [now modified] event on to push_event(). This latter interacts with
the container to send the event to the event channel, as
described. (Most push() implementations will do nothing to the event.
This could be provided as a default generated implementation.) On the
consumer side, push_event() will be invoked by the container as part of
event delivery. The push_event() operation performs type checks, as
described, before it invokes the consumer agent’s push() operation. This
process correctly handles the semantics and permits suitable places to
intercept or override event processing.

rejected

Because the interfaces between the Assembly and the
container/componentServer/servantActivator is not defined, these ones have
to be vendor specific.

Because the ExecutorSegmentBase and the HomeExecutorBase are not specified a
component is always container specific.

As a result an assembly provided by one vendor can only speak to
container/componentServer/servantActivator provided by the same vendor and
the container can only run (even in Java???) components that have
specifically ported to it.

The conclusion is that it is not possble to build an asembly that combine
components build on different CCM platform. All of the component have to be
ported to a single CCM platform.

Is it what is intended?

see below

a component wants to publish an event. So, it calls
Components::Notification::Event::create_channel(). The container contact the
(remote) Notification service, create a dedicated channel, connect to it and
return an EventConsumerBase to be used by the component to push any event to
the channel. Each time the push() method is called on the EventConsumerBase
it will create a structured_event and push it to the notification channel.

Now, another component (in another container/memory space/system) wants to
receive these events. So it calls Components::Event::subscribe() on the
first component passing a reference to an EventConsumerBase. The component
internally calls Components::Notification::Event::subscribe() passing the
remote EventConsumerBase reference. So now the container has to create a
(local) strutured_push_consumer and connect it to the channel it has
created. By doing this any event that it send to the channel will be bounced
back to it so that it can then push them to the (remote) EventConsumerBase
that have subscribed to the publish port.

This scenario doesn't seem right to me because the notification service is
then useless as all events are bounced back to the publisher. The container
could just call the push() method on each registered EventConsumerBase.

What seems to be really needed is a way to pass the reference to the
NotificationAdmin back to the second component so that the second component
can then subscribe through its own container to the Notification channel.

Another possiblity would be that the subscribe call accept a (remote)
strutured_push_consumer as parameter instead of the EventConsumerBase.

The last solution is that the publisher port is not designed to work with
the notification service but on its own.

I am certaimly missing something!!!!!

Could you explain how it is supposed to work?

rejected, see above

I found 2 (possibly) contradictory statement in 99-10-04 for "emits" ports.

1) in 62.4.1.2 The Event Interface

EventConsumerBase obtain_channel (in string supp_name, in EventHeader hdr)
raises (InvalidName);

The obtain_channel operation is used by the component to obtain an
EventConsumerBase which it can use to push events. This operation
corresponds to an emits declaration in component IDL. The supp_name string
identifies an Interoperable Naming Service (INS) name which is used to
identify the SupplierAdmin to be used by CORBA notification. The name is
associated with the SupplierAdmin thorough container specific configuration
data. The obtain_channel operation may optionally specify the EventHeader
required by CORBA notification which will be used for all events pushed to
this channel. If hdr is present, it is prefixed to all events pushed to this
channel. If not, it is defaulted as described in Section 66.4, "Event
Management Integration," on page 66-252. If the supp_name is not recognized,
the InvalidName exception shall be raised.

2) in 66.4.2 Transmitting an event

. channel lookup - for emitted events, this is the channel configured for
general use at container start-up, for published events, this is the channel
established by the container for the purpose of pushing this event type.

Section 62.4.1.2 seems to imply that there can be a different event channels
for each emit port while 66.4.2 seems to imply that there is only one event
channel shared by all emits ports.

What means "general use"?

What is the truth/intent?.

Could you make things clear?

I certainly preffer 1)

see below

The exception raised by Components::Events::subscribe() doesn't include the
Components::ExceededConnectionLimit exception raised by the
subscribe_source_name() 2.3 equivalent interface.

It should be added.

see below

In the componentAssembly DTD the executablePlacement is defined as follow:

<!ELEMENT executableplacement
( usagename?
, componentfileref
, componentimplref
, invocation?
, destination?
, extension*
)>
<!ATTLIST executableplacement
id ID #REQUIRED
cardinality CDATA "1" >

It seems to me that the DTD should not enforce the componentimplref as this
might depend on the deployment And there is no reason the assembler should
know where the executable is going to be deployed. For example the
componentimplref should be different between a Solaris, a Linux or an NT
placement.

Therefore I would propose to make componentimplref optional (as it is in
homePlacement) and change the executablePlacement definition to:

<!ELEMENT executableplacement
( usagename?
, componentfileref
, componentimplref?
, invocation?
, destination?
, extension*
)>
<!ATTLIST executableplacement
id ID #REQUIRED
cardinality CDATA "1" >

see below

When the component implementor wants to emits an event it has to use the
push() operation from the local Event interface.

It is not clear how the container will manage to discriminate the event and
select the channel this event need to be send to.

Nothing prevent a component to define several publisher and several emitters
and nothing force the events to be of different types on all of these
channels.

So either the spec is not clear enough on this process or the local push
method is missing some a parameter (like the emitter/publisher port name) to
help the container do his job.

rejected

in 99-08-05 the softpkg DTD is missing the "repository" element
specification. It could be copied from corbacomponent DTD.

<!ELEMENT repository
( ins

see below

in 99-08-05, the corbacomponent DTD is missing the "description" element
specification. It should be the same as the other DTDs and can be copied
from them

<!ELEMENT description ( #PCDATA ) >

see below

The equivalent interfaces as described within the document result in type mismatches when code is built to implement the functions generated from the CIDL component specification. That is, you cannot assign a consumer to a subscriber because the interfaces are parallel derivations and not an inheritance compatible derivations. The code prototypes must be changed to overcome this problem. We have tried three different approaches, but the one that seems to work best has the most impact to the IDL revisions.

Resolved by reference/clarification to 3746/ duplicate

In CORBA 2.3, a GIOP 1.2 LocateReply message made no requirements as to
the alignment of the LocateReply body. This meant that the LocateReply
body needed to be aligned only on a 4-byte boundary. With the resolution
for issue 2521, published with CORBA 2.4, the spec was changed to require
alignment of the LocateReply body on an 8-byte boundary.

The change is incompatible with the CORBA 2.3 definition because the receiver
must know where to look for the ReplyBody in the the byte stream following
the message header. (The LocateReply header is 12 bytes long, so changing
the alignment rules means that the LocateReply body has to start at offset 12
for CORBA 2.3, but has to start at offset 16 for CORBA 2.4.)

The change in alignment did not result in a version change of GIOP,
despite the incompatibility, so it appears that the change is simply illegal.

There are already deployed products that use the CORBA 2.3 alignment
rule; therefore, we cannot deploy a CORBA 2.4 compliant product without
breaking interoperability with already deployed CORBA 2.3 compliant products.

So, I'd like to request that we back out the change and continue to
permit a LocateReply body to be aligned on a 4-byte boundary. There was
never any need to change the alignment of the LocateReply body anyway because
a LocateReply header has fixed length and, therefore, cannot ever cause
remarshaling of the body due to a size change in the header. In other
words, the motivation quoted in the spec for the 8-byte alignment rule
isn't founded on fact, and the change should never have been made in the first
place. (See issue 4309 for details.)

No Data Available

The table on page 15-31 (Table 15-3 "GIOP Message Types and Originators")
is in error. For CloseConnection, it shows that only the server can
send this message but, in GIOP 1.2, either client or server can send
the message, as detailed in 15.5.1 and 15.4.7.

Also. in 15.4.7, we have:

In GIOP version 1.2 both sides of the connection may send
the CloseConnection message.

That should be "must", not "may".

see above

Add the missing entry with the same information as tk_objref.

add the missing table entry with the same information as tk_objref

If the server ORB sends back a NEEDS_ADDRESSING_MODE reply to the client indicating the prefered
addressing disposition, then is the client ORB required to 'cache' the prefered addressing
disposition per object reference, and use it for further requests to the server ?

to close without revision

I have a query about the intended marshalling format for Fixed. Is the
sending ORB always required to transmit the number of digits specified
in the IDL, or is it permitted to transmit fewer if there are leading
zeros?

Consider transmitting 123.45 as fixed<6,2>. Is the ORB permitted to
transmit

12 34 5c

or must it send the leading zero (plus another zero to pad the first
octet):

00 12 34 5c

In both cases, the receiving ORB knows it is expecting a scale of 2,
and the sign half-octet tells it where the digits end, so it can
correctly unmarshal the value as 123.45.

The discussion of issue 3431 suggests that the first option is not
permitted, and leading zeros must always be sent. However, the 2.4
GIOP spec makes no mention of how many digits should be sent. The
specification should be clarified to either explicitly permit or
explicitly forbid stripping of leading zeros.

Close with clarification revision

Section 15.3.2.7 of the CORBA 2.3 spec, which describes the CDR encoding
of strings, includes the following sentence in the first paragraph:

"Both the string length and contents include a terminating null."

It is not clear from this whether exactly one terminating null is required,
or whether more than one null can be included, with the string being terminated
by the first null.

Since IDL strings cannot include nulls (see 3.10.3.2: "OMG IDL defines the string
type string consisting of all possible 8-bit quantities except null"), any
additional nulls following the first terminating null cannot be part of the
string, and it therefore seems reasonable to ignore them.

Proposed Resolution:

Change the above sentence in section 15.3.2.7 to:

"Both the string length and contents include at least one terminating null."

Also make the same change to the corresponding sentence in the third paragraph
of section 15.3.2.7 describing GIOP 1.1 wide strings.

To close with clarification revision

15.4.6.2, "LocateReplyBody" says:

In GIOP version 1.0 and 1.1, Locate reply bodies are marshaled into
the CDR encapsulation of the containing Message immediately following
the Reply Header. In GIOP version 1.2, the Reply Body is always
aligned on an 8-octet boundary. The fact that GIOP specifies the
maximum alignment for any primitive type is 8 guarantees that
the ReplyBody will not require remarshaling if the Locate Reply
Header are modified.

The final sentence doesn't make sense because the LocateReply header is
a fixed-length header and therefore can't possibly cause remarshalling.

I suggest to delete the final sentence of this para.

see resolution of Urgent Issue 4314

There is nothing in the specification that explicitly states whether the
data in the body of a GIOP 1.1 Fragment message is marshalled relative
to the Fragment header or relative to the unfragmented message as a
whole.

The restriction in GIOP 1.2 that all fragments but the last must have a
multiple of 8 bytes, and the careful padding of the GIOP 1.2 Fragment
header to 16 bytes both strongly suggest that GIOP 1.1 fragments should
be marshalled only relative to the fragment header.

Proposed Resolution:

In section 15.4.9, right after the paragraph that reads:

"A primitive data type of 8 bytes or smaller should never be broken
across two
fragments."

add the following paragraph:

In GIOP 1.1, the data in a fragment is marshalled with alignment
relative to its position in the fragment, not relative to its position
in the whole unfragmented message.

Accept proposal above

I don't understand why tk_indirect isn't allowed as a top-level typecode.
This causes servere performance penalties for RMI-IIOP because the Java to IDL
mapping requires that Java objects of declared type java.lang.Object are
marshalled as CORBA anys. In the case of a Vector or HashTable with 100
elements, this means that 100 anys must be marshalled. If all of these are
of actual type foo, the restriction on tk_indirect means that all 100 of
these data values must repeat the typeCode for foo, which could be very large.
This causes very substantial overheads, since the space and time needed to
marshal the TypeCode for foo can greatly exceed that needed to marshal the
data for foo.

I understand why a nested tk_indirect cannot refer to any TypeCode outside
the scope of its enclosing top-level TypeCode. However, I don't think this
restriction needs to apply to a top-level TypeCode. We have made this
change experimentally without any adverse effects and we have discovered that
using tk_indirect for all the top-level foo TypeCodes after the first one can
speed up some common scenarios by at least a factor of 5 on end-to-end
measurements. There seems to be no downside to making this change.

I would therefore like to propose the following change to the section headed
"Indirection: Recursive and Repeated TypeCodes" within section 15.3.5.1:

Change the first bullet from:

The indirection applies only to TypeCodes nested within some “top-level”
TypeCode. Indirected TypeCodes are not “freestanding,” but only exist inside
some other encoded TypeCode.

by the following words:

The indirection applies only to TypeCodes nested within some “top-level”
TypeCode, or from one top-level TypeCode to another. Indirected TypeCodes
nested within a top-level TypeCode can only reference TypeCodes that are part
of the same top-level TypeCode, including the top-level TypeCode itself.
Indirected top-level TypeCodes can reference other top-level TypeCodes but
cannot reference TypeCodes nested within some other top-level TypeCode.

If this change finds favour, then we need to work out how it can be brought
into GIOP without causing problems interoperating with older ORBs that insist
on the stronger restriction of the current spec. This could perhaps be
added to the "wish list" for GIOP 1.3.

Close this issue and add it to the GIOP wish list

I have a question about the property.dtd file provided with the CCM spec.

in this file "simple" is described as follow:

<!ELEMENT simple
( description?
, value
, choices?
, defaultvalue?
) >

This seems to indicate that a "simple" element has to have a value in the
file. Therefore it is not clear how usefull is the optional "defaultvalue"
field. It also means that if the component or assembly provider wants to
provide the CPF files with the CCD and CAD files it has to put values into
them instead of just setting the default value. Obviously the best thing to
do would be to repeat the default value into the value but it seems strange
to me. The point is that if there is a default value provided the value
doesn't seem to be mandatory.

Also, in a way similar to the CAD file, where placement information are
added at deployment time, we may want to enable the component/assembly
provider to provide CPF skeleton files together with the CCD files and
skeleton CAD files. In this case the "simple" element may not contain any
"value".

I propose to replace this definition with:

<!ELEMENT simple
( description?
, value?
, choices?
, defaultvalue?
) >

Any thought

rejected

The definition for "choices" is as follow in the properties.dtd file:

<!ELEMENT choice ( #PCDATA ) >
<!ELEMENT choices ( choice+ )

knowing that the PCDATA for choice is supposed to hold one possible value
for the "simple" if I am right

I believe this is missing a bit of descriptive power. In case you want to
specify a range of 100 values you will have to give the 100 different values
each in its own "choice" element. It is very verbose !!!

We could add a range ELEMENT to the DTD as follow:

<!ELEMENT range (value, value)>

We could then change the choices ELEMENT as follow:

<!ELEMENT choices ( range | choice )+>

Any thought.

see below

The spec doesn't say whether or not resolve_initial_references() is allowed
to return nil. Clearly, it doesn't make sense for it to do that – we
should say so in the spec.

see below

in the absence of an RTF for the time service, I'm sending this to the
core RTF. (You could argue that this is a core issue anyway, since
the core depends on the time service for messaging.)

What is the interpretation of the time and tdf fields in a UtcT?

The spec shows:

struct UtcT

;

For TimeT, the spec says:

TimeT represents a single time value, which is 64 bits in size, and
holds the number of 100 nanoseconds that have passed since the base
time. For absolute time the base is 15 October 1582 00:00.

For UtcT, the spec says:

UtcT defines the structure of the time value that is used
universally in this service. The basic value of time is of type
TimeT that is held in the time field. Whether a UtcT structure
is holding a relative or absolute time is determined by its history.
[...]
The tdf field holds time zone information. Implementation must
place the time displacement factor for the local time zone in this
field whenever they create a UTO.

see below

There is no mapping for fixed types in the COM/CORBA mapping. Why has this been omitted? Is there a submission underway?

Close with answers to the qestions raised, as given above under Resolution

Please have a look at the news article below. Basically, the problem is
that we don't say in the spec what has to happen if I try to give
conflicting prefixes/IDs/versions to a module (which can happen if a module
is reopened).

My feeling is that we should deal with this the same way as for forward
declarations, that is, force the compiler to emit a diagnostic. I think
we should also add a note that this can't be enforced by the compiler
under all circumstances because of separate compilation.
> Orbacus distribution contains following IDL file.
>
> > #pragma prefix "omg.org"
> >
> > module CosNaming
> > {
> > typedef string Istring;
> >
> > struct NameComponent
> >

;
> > };
> >
> > #pragma prefix "ooc.com"
> >
> > module CosNaming
> >

;
>
> And here the error message of IDL to Visual Basic compiler.
>
> orbacusnaming.idl:16(8): Attempt to assign a different prefix
> to a forward-declared identifier
> orbacusnaming.idl:3(8): Position of the first identifier definition

The error message is misleading becuase there is no forward-declared
identifier here. But the compiler has a point – something strange is
going on there...

> I look in the CORBA specification and found that modules do have
> repository ids.

Absolutely.

> > Forward-declared constructs (interfaces, value types, structures,
> > and unions) must have the same prefix in effect wherever
> > they appear. Attempts to assign conflicting prefixes
> > to a forward-declared construct result in a compile-time
> > diagnostic. For example:
> [...]
>
> And what about reopened modules?

This part of the spec simply doesn't apply because it talks about
forward-declared things only.

> Which repository id do they
> have if someone use different prefix statements? I think
> they can have only one because the IFR of CORBA allows only
> one (if the repository version is equal).

Yes. The spec isn't really clear on this point. Here is your example
once more, simplified to the bare bones:

#pragma prefix "X"
module M

;

#pragma prefix "Y"
module M

;

The spec simply does not address this problem, so we have a hole. Thinking
about it, there are two possible interpretations:

1) Module M gets a prefix "X" initially. Then, when the prefix
changes to "Y" and the compiler sees M for the second time,
it could just ignore the prefix for M because M has the prefix
"X" already.

2) The compiler could notice that M previously got prefix "X"
and then complain when it sees M for the second time because
it would get a conflicting prefix.

For forward-declared things, the spec applies the philosophy that
the prefixes must not change. Seeing that a reopened module is somewhat
similar to a forward declaration (because the same definition can be seen
more than once), I'd be inclined to amend the spec to say that the prefix
for a module must not change.

For cases where the compiler can actually detect this, we can even force
a diagnostic. However, as for forward-declared things, this is not always
detectable by the compiler. In particular, if the reopened module is
reopened in different source files and the two source files are compiled
separately, there is no way for the compiler to detect that the module
is getting a different prefix in each source file. If the generated code
from the two files is linked into the same binary, you should at least
get a multiple definition error. But if the code for the two files ends
up in different executables, there is no way to detect the error at all
and you will get strange things happening at run time.

As far as the ORBAcus IDL is concerned, I think it needs fixing. The second
prefix pragma should be inside the module, to avoid the conflict:

#pragma prefix "omg.org"

module CosNaming
{
typedef string Istring;

struct NameComponent

;
};

module CosNaming

;

> Is my IDL2VB compiler again buggy or the Orbacus IDL file
> or the CORBA specification not clear?

Well, a little bit of all three I'll raise an issue with the core RTF.

> I recently solve all founded bugs in IDL2VB and it compiles now
> all examples of syntax chapter in CORBA spec and find
> all errors. CORBA is to difficult for humans...

That's why we use compilers for IDL instead of humans

Clarify as described below

CORBA 2.4.2 (01-02-01.pdf) 4.2.3.4 shutdown (relevant portion): "If the wait_for_completion parameter is TRUE, this operation blocks until the shut down is complete. If an application does this in a thread that is currently servicing an invocation, the BAD_INV_ORDER system exception will be raised with the OMG minor code 3, since blocking would result in a deadlock."

But does this mean that things will be as if the operation has not been called (suggested by the name of the exception raised?), or will they be as if the operation had been called with wait_for_completion FALSE (seems more appropriate)? Or should the implementation decide, and should it just use an appropriate completion code? In this case, is COMPLETION_MAYBE allowed? Letting the implementation decide puts a higher burden on the developer, though, if s/he wants to write portable code, so that developer may decide to just program for the current implementation...

This question has additional relevance for me because I'm implementing an ORB.

Clarify that BAD_INV_ORDER is raised in this case with COMPLETED_NO

For local interfaces, we seem to have internal inconsistencies in the spec.
For one, it is not clear whether or not a local interface implicitly inherits
from Object. There is one sentence in the spec that seems to imply that
there is implicit inheritance from object, on page 3-23 of the 2.5 draft
(http://doc.omg.org/ptc/1-6-10):

Any attempt to marshal a local object, such as via an unconstrained
base interface, as an Object, or as the contents of an any, or to
pass a local object to ORB::object_to_string, shall result in a
MARSHAL system exception with OMG minor code 4.

This implies that I can at least try to pass local object as CORBA::Object,
which implies that local interfaces do indeed implicitly inherit from Object.

But then, a bit further down, it says:

The is_a, get_interface, get_domain_managers, get_policy,
get_client_policy, set_policy_overrides, get_policy_overrides, and
validate_connection pseudo-operations, and any DII support
pseudo-operations, may result in a NO_IMPLEMENT system exception
with minor code 3 when invoked on a reference to a local object.

"May result in a NO_IMPLEMENT system exception"? I would suggest "shall"!

But, more seriously, I can't call is_a() on a local interface. In turn,
that seems to imply that I can't narrow a local interface either, but
narrowing is clearly necessary in the presence of inheritance for local
interfaces.

It seems that local interfaces must inherit from Object. After all,
it would be difficult to see, for example, how resolve_initial_references
can return a reference to the Root POA if it were otherwise... But then,
if local interfaces do inherit from Object, It doesn't make sense to
prohibit calling is_a() on them.

Related to that then is the question of "What is the repository ID of
a local interface?" Given that they can be narrowed, it would seem that
they must have repository IDs. (Although, you could argue that narrowing
is to be achieved via some mechanism other than repository IDs – that
would also permit is_a() not to be supported and would make narrowing
an issue that is specific to each language mapping.)

But the inheritance issue seems serious – if something doesn't inherit
from Object, I can't return or pass it as an Object, but we are doing
just that for local objects.

I think this will require some careful thought. We don't want to find
ourselves in yet another maze of twisty little passages, all different,
as we did with pseudo-objects...

Incorporate changes and close issue

the terms "pseudo-object", "pseudo-interface", and "PIDL" appear in many
places in the spec. However, there does not appear to be a definition
of what these things actually are anywhere in the spec. Now, for many years
now, I've been telling people that PIDL objects differ from normal ones
in the following ways:

• They don't inherit from Object.

• They can't be invoked via the DII.

• They don't have definitions in the IFR.

• They can't be passed as arguments to remote operations
  (except for TypeCode).

• They may have special mapping rules.

I know that, once upon a time, when I first wrote these points into a CORBA
training course, I didn't just make them up – I found them in the spec.
However, I'm damned if I can find them now. I looked in the 2.0 spec as
well as the 2.4.2 spec to no avail. Can someone help me out?

At any rate, we should add the definition somewhere because, write now,
we have lots of free-floating terms in the spec.

On a related note, by searching for "pseudo", I found a few places where
it is stated that "pseudo-objects do not have object references". That
seems to be wrong. After all, we pass these things across (local) interfaces
by reference (instead of by value) and, at the language mapping level,
pseudo-objects have references that are indistinguishable from any other
reference. We should correct this.

see above

Steve's and my book contains a bit of code that pretty-prints a TypeCode.
(See page 704ff, in particular, 709-711.) No big deal – just write
a recursive function that does a depth-first traversal of a TypeCode tree
and prints things out, except for one thing: recursive types.

For recursive types, the code has to be careful not to get trapped in
infinite recursion. In essence, this means that the pretty-printer has to
remember which TypeCodes it has already seen and end the recursion if it gets
to a TypeCode that was printed previously. This is where we run into
problems because there is no legal way to do this:

• I cannot rely on the repository ID in the TypeCode to determine
  TypeCode identity because the repository ID for structs and
  unions is optional prior to GIOP 1.2, but recursion happens
  via structs and unions. (A GIOP 1.2 implementation may interoperate
  with a GIOP 1.0 or 1.1 implementation and still end up sending
  TypeCodes without repository IDs.)

• The code in the book uses is_equivalent() to determine whether
  it has seen a TypeCode previously. However, doing this is
  completely illegal (even though it happens to work with most
  ORBs) because:

• is_equivalent() does not provide object identity.

• TypeCode is a pseudo-object, and pseudo-objects do
  not inherit from CORBA object. This means that TypeCode
  doesn't even have an is_equivalent() operation that I
  could call.

So, as far as I can see, there is no compliant way to reliably and portably
determine TypeCode identity and, as a result, I can't ever reliably parse
a TypeCode...

I can see several solutions for this problem, all with different drawbacks:

1) Add an identity() operation of some kind to TypeCode.

An ORB that receives a TypeCode would have to make sure that
it generates a unique ID for each TypeCode. But that's not
all that easy to implement – in particular, if we have an
older TypeCode where all the optional bits are missing, we
can't reliably establish object identity for a TypeCode.
(Only structural comparison is possible.)

2) Add an identity() operation to TypeCode, but have the TypeCode's
identity generated at the sending end instead of the receiving
end.

Major drawbacks: the identity would have to large because it
needs to be globally unique (e.g. a UUID) and it would change
the marshaling of TypeCodes.

3) Add is_equivalent() and hash() operations to TypeCode.

This might break existing ORB implementations because a lot
of ORBs seem to inherit from Object for TypeCode and other PIDL
objects, even though they shouldn't.

4) Make PIDL objects implicitly inherit from CORBA::Object.

Note that making the repository ID mandatory is impossible because we
can't legislate for existing GIOP 1.0 or 1.1 implementations...

On a related note, we seem to have further problems with the idea that
PIDL objects don't inherit from CORBA::Object. For example, in the C++ mapping,
pseudo-objects such as TypeCode, ORB, etc. can be passed as Object_ptr
(for example, to CORBA::is_nil()). This really means that the C++ mapping
(and possible mappings for other languages) are completely in conflict
with the core spec...

My feeling is that option 4 is really the least-intrusive one. But I'm
not sure that I fully understand all the ramifications of making that change.

see above

Please take a look at the resolution of issues 4285 and 4306 in
> ptc/2001-06-08 - the RTF report that is up for recommendation to adopt
> at this upcoming meeting, and see if they do not fix these problems.
> 4285 fixes the BAD_OPERATION problem most definitely. 4306 seems to fix
> the OBJ_ADAPTER problem too, although slightly differently from how you
> suggest. If these fixes address the problem that you raise in your
> message, could you please ask Juergen to not create an issue?I didn't CC issues, so I don't think Juergen will create an issue (at least,
that was the intent). My apologies for the duplication. However, looking
at 4285 once again, I think there may be a problem:

In order to return something that means "ServantManager returned wrong
servant type", I think the ORB core has to insert an active check
at the point where the servant manager returns. If it doesn't, it will
either get an unmarshaling error or return a BAD_OPERATION exception with
some other minor code when it detects that the operation isn't in the
function pointer table for the servant. In the latter case, the ORB won't
know anymore why the operation is missing (for example, it could also
be missing because the client used the DII to invoke a non-existent operation.)

I am also not sure whether BAD_OPERATION is really the correct exception to
use. To me, BAD_OPERATION tells the client "you invoked an operation that
doesn't exist". If we give this exception to the client when it invokes
an operation that's perfectly good, that's highly misleading because the
actual problem isn't with the client, but with the servant manager.

So, I think that using OBJ_ADAPTER, as I suggested, would be better.

For the resolution to 4306, I think we also have something that is suboptimal.
That's because minor code 2 say "Servant not found" in table 4-3. But
I don't see how this is possible. Basically, a servant manager isn't allowed
to return a null servant. If it can't find the servant, it's supposed to
throw a system exception. So, a servant manager that returns null is simply
broken and needs to be recoded. 4306 (by using "Servant not found" as
the explanation of minor code 2) is misleading, because that condition simply
can't happen.

So, without trying to create a procedural mess, could we reconsider the
resolution to these two issues, maybe for the next vote?