I have a question about GIOP wstring encoding. Section "15.3.2.7 Strings
and Wide Strings" in CORBA 2.3.1 says:

For GIOP version 1.1, a wide string is encoded as an unsigned long
indicating the length of the string in octets or unsigned integers
(determined by the transfer syntax for wchar) followed by the
individual wide characters. Both the string length and contents
include a terminating null. The terminating null character for a
wstring is also a wide character.

In the sentence above, I believe that the "length" represents number of
octets (in the case of byte oriented codeset) or number of unsigned
integers (in the case of non-byte oriented codeset).

For example,

"abc" (ASCII code) ----> length is 4 (including one null terminate)
L"abc" (Unicode, USC2) ----> length is 4 (including one null terminate of wchar)

Is my understanding right?

see above

Suppose a GIOP 1.2 request message is sent for an operation with no
argument. In this case the request body is empty because there is no
argument.

Furthermore, the whole request message is non-fragmented, i.e. the
2nd least significant bit of Flags in the request header is 0. Now if the
request message header ends on a boundary which is not 8-byte
aligned. Should the request message be extended with extra padding after the
request message header to make the whole request message multiple of 8?

I think the relevant statement is in section 15.4.1 (page 15-31):

"For GIOP version 1.2, if the second least significant bit of Flags is 1,
the sum the message_size value and 12 must be evenly divisible by 8"

My intepretation of the statement is that the condition I just described
does not meet this critera. Hence the message should not be padded to
multiple of 8. It should just be ended with the end of the message header,
just like previous GIOP versions.

I'm asking for clarification on this issue because I'm seeing a different
behaviour in another ORB implementation and would like to pre-empt any
interoperability problem in future.

see above

Chapter 15 (formal/99-07-19), page 15-51 last para of section 15.7.2, and
Chapter 13 (formal/99-07-17), page 13-36 last para, assert that "no 'well known'
ports have been allocated", and then proceeds to state that individual
implementations must use some unallocated port and document it.

The statement about "no well known port has been allocated" needs to be revised
to reflect that a well known port (683 for IIOP) has been allocated. Then we can
change the statement about what individual implementations are expected to do by
merely replacing the "must use some unallocated port" by a "may use the well
known port or may use some unallocated port and document it" or some such.

see below

I do have a quick question on one part and that is
Section 15.7.3 IIOP IOR Profile Components. This first paragraph has the
following line in it: " All these components are optional presence in the
IIOP profile
and cannot be dropped from an IIOP 1.1 or 1.2 IOR". Now I must admit that I
am
new to this CORBA thing, but is there something wrong with this sentence?
I am not quite sure what this means and the grammar seems quite odd ("are
optional prensence"?). Any chance someone could translate?

see above

Is GIOP 1.x really sustainable any more?
We've got implementation nightmares because:

• Features haven't been thought through properly
  eg Fragment in 1.1, BiDir in 1.2

• Simple backwards compatibility is being lost
  eg ReplyHeader v1.2 has fields in completely different places to
  previous versions, albeit for very good reasons.

• The TypeCode CDR version problems

• Not enough information in certain messages
  eg MessageError can't indicate which message may have caused a
  problem, and certainly can't describe in what way there was an error.

see above

I have a number of issues with the Software Package Descriptor section of
the CCM specification (Component Spec - Volume I, orbos/99-07-01.) I have
not found answers to issues raised below in either the components-ftf
archive, or the issues list.

ISSUE - The softpkg descriptor example uses an "id" attribute, which isn't
defined in the softpkg.dtd.

>From page 10-305, 10.2.1 A softpkg Descriptor Example, CORBA Components -
orbos/99-07-01:

<idl id="IDL:M1/Bank:1.0" ><link href="ftp://x/y/Bank.idl"/></idl>

According to the softpkg.dtd, (page B-435, B.1 softpkg.dtd, CORBA Components

• orbos/99-08-05, ) the idl element is defined as follows:

<!ELEMENT idl
( link

The same definition can also found in section 10.2.2.14, The idl Element (,
page 10-311, CORBA Components - orbos/99-07-01.) There are no attributes
defined for the idl element.

see below

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.

In section 13.6.8 of CORBA 2.4.2 (formal/01/02-01), at the top of page
13-29, it says:

The high-order 20 bits of service-context ID contain a 20-bit vendor
service context codeset ID (VSCID); the low-order 12 bits contain the rest
of the service context ID. A vendor (or group of vendors) who wish to
define a specific set of system exception minor codes should obtain a
unique VSCID from the OMG, and then define a specific set of service
context IDs using the VSCID for the high-order bits.

The VSCID of zero is reserved for use for OMG-defined standard service
context IDs (i.e., service context IDs in the range 0-4095 are reserved as
OMG standard service contexts).

The VSCID-related text was added by the Interop 1.2 RTF as per RTF report
as in document number interop/98-01-04, and revised pages as in document
number interop/98-01-03. However, at about the same time OMG staff
established a convention that OMG should allocate vendors a 24-bit "service
tag", which is in fact the same as a VSCID. Since then, some 47 of these 24
bit service tags have been assigned to various vendors.

At the risk of having the tail wag the dog, I propose we resolve this
conflict by revising these paragraphs in the CORBA spec as follows:

The high-order 24 bits of a service context ID contain a 24-bit vendor
service context codeset ID (VSCID); the low-order 8 bits contain the rest
of the service context ID. A vendor (or group of vendors) who wishes to
define a specific set of system exception minor codes should obtain a
unique VSCID from the OMG, and then define a specific set of service
context IDs using the VSCID for the high-order bits.

The VSCIDs of zero to 15 inclusive (0x000000 to 0x00000f) are reserved for
use for OMG-defined standard service context IDs (i.e., service context
IDs in the range 0-4095 are reserved as OMG standard service contexts).

see below

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

After reading the definition of the import declaration, it is not at
all clear what its effect is.

Suppose the "well-known set of IDL specifications" consists of

module A {
module B {
interface C {
struct S

;
};
};
};

Now consider the import statement

import A::B;

According to the draft, "Names that occur in IDL declarations within
the importing specification may be resolved to definitions in imported
scopes." What is a "Name" in this context? Is it an <identifier>, or
is it a "<scoped_name>"?

It is unclear whether in this context, the definition

interface D : C {};

would be correct or not. The spec may be interpreted that name "C"
resolves to ::A::B::C, i.e. that the name "C" is appended to the
imported scopes, forming a fully-scoped name. If that is the intended
meaning, the text should explain how to deal with conflicts.

Alternatively, given the text "Imported IDL name scopes exist in the
same space as names defined in subsequent declarations in the
importing specification." would suggest that

interface D : B::C {};

is well-formed: "B" would be the name of the imported scope, so it
exists in the same space "D", and can thus be used for qualifications.

Furthermore, the text could be understand to mean that

interface D : ::A::B::C {};

is allowed. The "definition in the imported scope" has the name
"A::B::C", so this is the name to be used in the importing
specification.

see below

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

In order to compile the Components.idl file with a compiler
compliant with OMG IDL2/IDL3/CIDL/PSDL grammars simultaneously,
it is required to apply some changes in CCM APIs:

• In ptc/2001-11-03 draft chapter 61 page 61-225, the following IDL

valuetype FacetDescription : PortDescription

;

should be replaced by

valuetype FacetDescription : PortDescription

;

because 'facet' is a CIDL keyword.

• In ptc/99-10-04 chapter 62 page 62-141, the following IDL is defined

exception Rollback { };
// ...
local interface Transaction

;

Here there is a conflit name between the exception Rollback
and the operation rollback.

In order to avoid this, the exception Rollback should be renamed
RollbackError. Then the previous IDL should be replaced by:

exception RollbackError { };
// ...
local interface Transaction

;

In the commit operation description page 62-142, the Rollback exception
should be replaced by RollbackError.

In table 64-7 page 64-197, the Rollback exception of the commit operation
should be replaced by RollbackError.

• In ptc/99-10-04 chapter 62 page 62-151, the 1st 'home' parameter
  of the HomeRegistration::register_home and unregister_home operations
  implies a parser error with a CCM IDL compiler as 'home' is a keyword.

The 'home' parameters should be replaced by 'home_ref'
Ditto in the following 'register_home' and 'unregister_home'
operation descriptions.

• In ptc/99-10-04 chapter 62 page 62-155, the following IDL

get_oid_from_ref (in Object ref)

should be replaced by

get_oid_from_ref (in Object objref)

because 'ref' is a PSDL keyword.

In the 'get_oid_from_ref' operation description page 62-156,
replace 'The ref parameter' by 'The objref parameter'.

• In ptc/99-10-04 chapter 62 page 62-162, the following IDL

get_cid_from_ref (in Object ref)

should be replaced by

get_cid_from_ref (in Object objref)

because 'ref' is a PSDL keyword.

In the 'get_cid_from_ref' operation description page 62-163,
replace '(ref)' by '(objref)'.

• In ptc/2001-11-03 draft chapter 69 page 69-551, the following IDL

void remove_container(in Container ref) raises (RemoveFailure);

should be read as

void remove_container(in Container cref) raises (RemoveFailure);

because 'ref' is a PSDL keyword.

• In ptc/2001-11-03 draft chapter 69 page 69-553, the following IDL

void remove_home(in CCMHome ref) raises (RemoveFailure);

should be read as

void remove_home(in CCMHome href) raises (RemoveFailure);

because 'ref' is a PSDL keyword.

Accept the previous required changes.

I wanted to point out that the use of the name "ref" or "Ref" in
> the introspection API may be a problem because "ref" is a
> reserved word in PSDL and therefore any PSDL file that
> includes the CCM IDL file will cause compiler errors (this has
> happened to me when using the OpenORB PSDL compiler). If at
> all possible we should change the use of "ref" to "reference"
> or something else in the final version of the spec.

see below

ccm/01-08-04 says

"When a name scope is imported, the names of the enclosing scopes in
the fully-qualified pathname of the enclosing scope are exposed within
the context of the importing specification, but their contents are not
imported. An importing specification may not re-define or re-open a
name scope which has been exposed (but not imported) by an import
statement."

Now consider the following "well-defined set of IDL specs":

module X {
module Y {
module Z{};
};
};

and the following import statement

import X::Y;

Now, it appears that this declaration would make it ill-formed to
specify

module X{
interface another_interface{};
};

since "X" is an exposed scope. That appears to be inconsistent, since
clearly, reopening "X" is allowed without the import statement.

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

In ccm/01-08-03, section 3.6, there is a sentence

"In isolation, the scope token represents the scope of the
specification in which it occurs."

It is not clear what an "isolated scope token" is, since the scope
token is allowed only as part of a <scoped_name>, but never appears in
isolation. The intended meaning of this sentence should be clarified.

see below

in both documents orbos/99-07-01/6.3 and ptc/99-10-40/615.3 the language
mapping is noted as open issue.
Where are the language mappings for components ?

see below

In ccm/01-08-03, a sentence says "IDL module definitions may re-open
modules defined in imported name scopes."

Now, consider the following "well-defined set of IDL definitions":

module Y{};
module A{
module Y{};
};
module B{
module Y{};
};

and the import statements

import A;
import B;

Clearly, A::Y and B::Y are "modules defined in imported name
scopes". Does that mean that specifying

module Y{
interface another_interface{};
};

is now valid? If so, which namespace is extended?

It may be that this is meant to be an error (if so, where does it say
that?). In that case, consider the case that there was only a single
import:

import A;

Then, if this means that A::Y is extended, how could I specify a
re-opening of ::Y?

Alternatively, it may be that the authors thought of re-opening Y in
the form of

module A::Y{
interface another_interface{};
};

That, of course, is illegal syntax. Yet another interpretation is that
the draft intended to allow

module A{
module Y{
interface another_interface{};
};
};

However, this appears to be possible even without any import
statement.

See issue 4577.

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 chapter 69.9.1.2 Deployment Scenario on page 329 of ptc/99-10-04.pdf the
operation get_implementation() is refered as if it belongs to the
ComponentInstallation interface (called only "Installation"), but the
specification of that interface lacks it.

Duplicate, close

Dealing with the following IDL3 definition, a problem arises when
generating the IDL2 definitions (complete IDL2 mapping is enclosed at
the end of this mail).

module example {
valuetype AnEvent : Components::EventBase

;

component Producer

;

component Consumer

;
};

According to the chapter 5 of the CCM specification, the publishes
definition of the Producer component is mapped to the following
definition (excerpt).

interface Producer : Components::CCMObject

;

In the mean time, the consumes definition of the Consumer component is
mapped to the following definition.

interface Consumer : Components::CCMObject {

::example::ConsumerEventConsumers::AnEventConsumer
get_consumer_input();

};

We can see that two versions of the "AnEventConsumer" interface have
been defined in two distincts modules. Thus the following Java
lines are not correct:

example.Producer p = ...;
example.Consumer c = ...;

p.subscribe_output(c.get_consumer_input());

The Java compiler will refuse to compile the last one, producing an
error like "BadTypeCoerce". However, in the IDL3 definitions, both
components have been defined in order to be used together. (sic!)

Thus, we think that the mapping for a Consumer should not be based on
the component definitions, but on the event definition itself. It
would then avoid multiple (incompatible) definitions of the consumers.
This mapping could be defined in two distinct ways.

see below

Looking a the <Assembly> interface, a question arises. When providing
the assembly descriptor location, a logic description of the
application to deploy is provided. But, how are set the pysical hosts
to be used for the deployemnt of the logic configuration? No hooks is
provided to the deployment tool (as there are no interfaces for the
tool) in order to provide these information, and no operation is
available on the assembly interface to do so. Is there an extension of
the <Assembly> interface in order to contain this information?
Otherwise, how could the application be deployed?

Thinking about what should be provided, it is necessary to assign a
logical name contained in the assembly descriptor to a physical host
name. Maybe an extension to the assembly descriptor filled at
deployment time is the solution? The second possible choice crossing
my mind is an IDL structure (in fact sequence of structure) that could
be provided to the assembly object.

rejected

What about <i>valuetype factories</i>?

<p>In the context of a component dealing with events, the aspect of
<i>valuetype</i> factories has not been really mentionned in the spec,
especially in the deploiement process.
If I am right, dealing with <i>valuetypes</i> in a program means to
instantiate and to register a factory for this <i>valuetype</i> to the
ORB. In the context of the CCM, a component and its home is installed
into a generic container which may not know the <i>valuetype</i>.
Thus, the <i>valuetype factory</i> may have to be installed at
deployment time. </p>
<p> According
to the similarity in the <i>home</i> and <i>valuetype factory</i>
concepts, it may be a good solution to add an entry in the CORBA
Component Descriptor OSD file to define the <i>valuetype factory</i>
(which would have to be included in the component package) required by
the component as well as to define a standard name scheme for their
entry points. Here is an draft example of what it could look
like. Relationships / dependencies between components and <i>valuetype
factories</i> also have to be introduced.</p>

<!--
<softpkg>
...
<implementation id="...">
... all the environment stuff ...
<descriptor type="Event Factory">
<fileinarchive>...</fileinarchive>
</descriptor>
<code type="DLL">
<fileinarchive name="bank.dll" />
<entrypoint>createEventFactory</entrypoint>
</code>
</implementation>
...
</softpkg>
-->

<p><tt><softpkg>
<br>  ...
<br>  <implementation id="...">
<br>    ... all the environment stuff ...
<br>    <descriptor type="Event Factory">
<br>      <fileinarchive>...</fileinarchive>
<br>    </descriptor>
<br>    <code type="DLL">
<br>      <fileinarchive name="bank.dll" />
<br>      <entrypoint>createEventFactory</entrypoint>
<br>    </code>
<br>  </implementation>
<br>  ...
<br></softpkg></tt></p>

<p>The second solution could be to include the code for <i>valuetype
factory</i> creation in the <i>home</i> implementation, which mean
less specification: "The home has to install any valuetype factory
required by the component." would be enough. However, this second
approach may not be as much portable as the first one (as long as a
<i>home</i> may be portable between containers, which IMHO should be
possible).</p>

see below

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

he following sub-issues need to be addressed to make sure that CCM/EJB
bridge implementations are interoperable. In particular, these sub-issues
have in common that the current definition of the bridge relies on the
Java-to-IDL mapping, which in certain cases does not match the requirements
of the EJB-to-CCM mapping.

Sub-issue: METHOD NAMES IN STANDARD INTERFACES

The names for some methods defined on standard interfaces, for example
<home-name>Implicit.find_by_primary_key or <home-name>Implicit.create,
differ from the names that their EJB counterparts get mapped to under
Java-to-IDL (in the example these would be
<home-name>.findByPrimaryKey and create__keytype, respectively). When
this happens, the translation from one form of the name to the other
can happen at either the client or the server side of the bridge. FOR
INTEROPERABILITY, it is necessary to eliminate this ambiguity. Choices
for doing this include requiring the client stub to always do the
translation or requiring the server skeleton to take into account both
name forms.

The actual problem we are getting hit by here is overloaded names. Methods
like remove and create in EJBHome and user-defined EJB homes can only be
mapped to remove_XXX and create_XXX under Java-to-IDL, yet the
definitions of the corresponding methods in <home-name>Implicit are remove
and create, respectively. I can understand that these implicit home names
were defined as such because <home-name>Implicit is a standard interface
(although the fact that its name is prefixed by <home-name> is a bit
troubling) and, if for no other reason, because the XXX in create_XXX
cannot be known in general. So, if we stick to the standard names, there is
a mismatch. Notice however that I said that the mapping is done under
Java-to-IDL. Perhaps I should not say that but the CCM spec is not clear
about this and in fact it states that the create methods in an EJB home are
mapped to factory names under Java-to-IDL. So we may actually be talking
about two different issues: (1) use different mapping rules for create with
no primary key, in which case we need to ammend the spec to this effect;
(2) perform a translation, in which case we have an interoperability issue.

Sub-issue: HANDLING STANDARD EXCEPTIONS

Standard exceptions thrown by EJB methods, such as
DuplicateKeyException, have a mapping specification to IDL (under the
current Java-to-IDL specification) that does not match the exceptions
that they map to under the CCM spec (in the example this would be
DuplicateKeyValue). This requires that the bridge perform a run-time
translation of exceptions from the Java-to-IDL mapping to the CCM
mapping at either the client stub or the server skeleton. FOR
INTEROPERABILITY, it is further necessary that the location of the
translation be fixed. Early prototype implementation suggests that it
is more advantageous for the client stub to perform the translation
since otherwise the server skeleton would need to know what kind of
client it is talking to: a CCM client or an EJB client. A larger issue
that this falls under is the reconciliation of the Java-to-IDL mapping
with the EJB-to-CCM mapping. If and when the larger issue is resolved,
this issue would largely disappear.

This also falls under the Java-to-IDL mismatch. Our choices seem to be: (1)
define the standard exceptions, e.g. Components::DuplicateKeyValue, as if
they had been mapped from Java under Java-to-IDL, (2) map the exceptions
from Java under rules different from those on Java-to-IDL; (3) perform a
translation. Choice (1) may be too intrusive but it could be rationalized
with a "integration with EJB" argument. Choices (2) and (3) are similar to
the above.

Sub-issue: PASSING A PRIMARY KEY PARAMETER

A number of methods defined by standard interfaces, such as remove
defined by EJBHome, include in their signature a primary key value and
define its type to be java.lang.Object, which under RMI-IIOP is mapped
to CORBA::Any. Since the primary key is actually an object passed by
value and thus mapped to an IDL value type, a run-time translation
must be performed from the value type to Any and viceversa whenever a
method that includes a primary key is called. FOR INTEROPERABILITY, it
is necessary that the location of this translation be fixed. Choices
for doing this include requiring the client stub to always do the
translation or requiring the server skeleton to take into account both
a value or an Any that could possibly be coming from any given
client. In additon, if a primary key is returned it may be more
advantageous for the client to perform this translation, since the
server skeleton may not know what form the client is expecting.

Here again the problem is that, under Java-to-IDL, java.lang.Object gets
mapped to ::java::lang::Object (not CORBA::Any actually, as per the actual
Java-to-IDL I am looking at) for methods like EJBHome.remove, whereas the
key is expected to be passed as a value type. So the choices seem to be:
(1) use rules other than those in Java-to-IDL for the mapping or (2)
perform a translation.

see below

What exactly is meant in chapter 69.7.2.3 by component archive file? It is
not defined anywhere. Is it a software package descriptor or a software
package? At least it is not a CORBA component descriptor as shown in the
example in chapter 69.7.1. The text there is like:

<componentfile id="A">
<fileinarchive name="ca.ccd"/>
...

Is the sufix ccd right?

see below

Document orbos/99-08-13, line 9 and further, contradicts with
orbos/99-07-01,
Chapter 4.4. The production rules for typePrefix and typeId contain a
";",
where file orbos/99-08-13 omits them.

Document orbos/99-08-13, lines 1-6, contradicts with orbos/99-07-01,
Chapter 4.2. The production rules for import contain a ";",
where file orbos/99-08-13 omits them.

see below

The mapping between EEJB metadata and the IR is missing in the
current specification .Resolution: Define the mapping

see above, rejected

Moving existing interfaces from the CORBA module to a new IR module breaks
backward compatibility. Hence they should be moved back to the CORBA module. The
elements that are newly added can go into a new module, and interfaces
corresponding to the existing ones with the same names can be placed in the new
module, with these interfaces deriving from the existing corresponding
interfaces in the CORBA module, thus allowing all CORBA3 IR interfaces to be
accessed from a single module.

This also fixes a related problem regarding separation of the TypeCode stuff,
specifically TypeCode factory. It is broken in the current spec because certain
types used by the typecode factory were inadvertently moved to the IR module.

see below

In section 69.4.5.45, the "rights" element is mentioned, but the "rights
combinator" elemnt is not. Given a set of "rights" it is not possible to
determine how to cobine them without the "rights combinator" as specified in
CORBAsec. Suggest we add a "rights cobminator" element, consistent with the
definition of rights combinator in CORBAsec.

see below

ISSUE - What is the purpose of the "name" element as used in the
"dependency" element?

See section 10.2.2.7, The dependency Element (, page 10-308, 10.2.1 A
softpkg Descriptor Example, CORBA Components - orbos/99-07-01.) Section
10.2.2.20, The name Element, describes the name element as an optional
element of the "author" element, and is meant to identify the author. So
does the name element identify the author of the dependency, or is it used
to identify the dependency itself?

see below

The FTF draft does not allow a CIDL composition to be
included in a module.

Discussion: In the FTF Draft, the CIDL BNF (Section 60.3) is not yet
tied into IDL syntax. As it stands, a composition cannot be embedded
in a module. The draft recognizes that with the note (Section 60.4):

see below

When a component type is implemented, it inherits a specialized
interface for callback functions, for example SessionComponent. In
this context, why should home implementations be unspecialized? Using
a specific home type, deployment could be improved when performed in a
multi-actor context. As the cooperation between containers and homes
is unspecified, using multi-actors components seems unreachable. One
particular aspect is how the container <Context> interface si provided
to the component instance. Using a well defined specialized home
interface would solve this problem easily. Thus, avoiding the use of
wrappers for example which are another solution, but far more complex.
Such an interface should be defined for each component type category.

As an example the following interface could be a basis for session
component homes. (there must be other operations to add here, but I
have not foudn them yet.)

interface SessionCCMHome : CCMHome

;

rejected

7. Where is HomeExecutorBase interface defined? I only saw it used in
the packaging and deployment model. If it is a standard interface
which is returned (how could it be non standard), shouldn't it be
defined somewhere? (Same remark for ExecutorSegmentBase
interfaces. It may be defined in the last Components.idl, but I did
not find one more recent than orbos/99-08-13.)

See the resolution for issue 4574.

6. In example p.615-86, shouldn't myToonImpl extends ToonSessionImpl
(presented in the previous pages) instead of ToonImpl (which is not
defined)? The same classname is used in pages 96-98, but it seems
correct in this case.

see below

5. Even if it is only an example, p.615-85 ToonTownImpl implements
ExecutorSegmentBase, shouldn't it be HomeExecutorBase?

see below

4. Why does not CCMHome include the operation create_component() ? I
understand that a component created by a home with keys should not
offer this interface, however according to the exemple in the spec
Container operation install_home() returns a CCMHome, thus how
could a component be created in this context? Does it imply that
you know if the home is keyless or not, thus narrowing it before
use? Don't you find strange to have the remove operation but not a
default create in the CCMHome interface?

rejected

3. Why isn't the operation <string get_implementation(in string iuuid)>
defined in the interface ComponentInstallation while being used in
ptc/99-10-04 p.69-329 item 9? (Where Installation should be
replaced by ComponentInstallation don't you think?) Moreover, this
operation is required for an Assembly to find the location of a
component implementation in order to load it in a container.

see below

1) Some concepts from the CORBA metamodel (component, facet, receptacle,
event publishing/emission/consumption) are also in P/D metamodel but the
definitions from the CORBA metamodel are not directly reused.

Recommendation: Analyze where reuse is appropriate and adjust the P/D
metamodel accordingly.

2) The P/D metamodel has the notion of files (e.g. configuration property
files and some other files) where some metadata are stored. The hand-coded
DTDs treat these files as types in their own right, i.e. they conceptualize
them as files, and some of the other types point to the file types. This
is approach is mimicked in the metamodel. However, it might not make sense
in the metamodel because, in a repository context, you are referencing
other information in the repository and not necessarily a file. The way
the metamodel is now, when something references one of these files you lose
the metadata trail. The file metaclass itself does not have structural
features pointing to metaclasses that define the contents of the file. You
have to go elsewhere (i.e. to the property file Package) to get that
metadata and there is no reference to the property file Package.

Recommendation: It might make more sense for references to the file
metaclass to instead reference the top level element of the property file
Package so that you can "follow the metadata trail." If someone wants to
break out the properties metadata in a file, then the generated DTD should
allow that, i.e. the part that needs to go into a properties file should be
able to be self-contained without external references.

rejected, See issue 4575.

ISSUE - The description of the "implementation" element explains the
"variation" attribute, but the attribute is not part of the definition.

>From page 10-32, CORBA Components - orbos/99-07-01: "The variation attribute
is used to indicate a variation from a normal implementation." But the
definition of the implementation attribute list only lists the "id"
attribute. The variation attribute is not part of the definition as given in
softpkg.dtd either (, page B-419, B.1 softpkg.dtd, CORBA Components -
orbos/99-08-05.)

see below

Summary: At present there is no formal mechanism or process for versioning the
CORBA Core. Indeed, it is somewhat hard to figure out what is part of
the CORBA Core. In Rev 2.3 we tried to at least bring all the IDL for
the Core together in pieces at logical places, e.g. ORB interface,
Object interface, IR Interfaces etc. In addition we also have the
PortableServer module and the GIOP and related modules, the versions of
all of which have to match for the resulting system to have any hope of
working as advertized. I guess the basis of the current state of
affairs is that - the vendor delivers the core, and therefore one can
trust the vendor to deliver the right things. This model tends to break
down in situations where people can download bits and pieces of a Java
ORB at different times and then try to make the whole thing work
together.

rejected, see above

In ptc/99-10-04, the production 104

<readonly_attr_declarator >::=
<simple_declarator> [ <raises_expr> ]

see below

The draft component specification (ptc/99-10-04) explains that CIDL is
a superset of IDL. This is a derivation from the specification
voted-on in the PTC (orbos/99-07-01), which specified that CIDL is a
superset of PSDL.

Also, declaring CIDL not to be a superset of PSDL means that the
<catalog_use_dcl>, <abstract_storage_home_binding> etc become
meaningless, as they refer to entities from PSDL.

Proposed Resolution: Declare CIDL to be a superset of PSDL.

See issue 3065.