This form contains a series of questions that need to be answered. As you go about answering the questions, please keep the following things in mind:

• While it is not required that each question be answered at this time, all questions must have answers before the response is submitted to The Open Group for review and publication.
• Press the "Save" button at any time to save work in progress. Once the work has been saved, there is the option to continue editing if required.
• Many questions have instructions to assist in development of answers. They are marked with the indicator. Please look at the instructions carefully.
• Although HTML markup can be included in answers, this is not recommended apart from basic tags such as <p> and <br>, since incorrect markup could effect the format of other items in the document.
• Questions on this system should be addressed to the Conformance Statement manager at The Open Group.

Enter the name of the Organization that produced the implementation and the name of the author of the Conformance Statement.

1. CORBA 2.3

Product Information

Environment Specification

Product registration applies to software products operating in a specific hardware or hardware/software environment.

A product may be registered in all members of a binary-compatible family of products on the basis of a single test report.

Answer the questions for each binary-compatible family. Alternately, provide the answers in the Appendix at the end of this document.

	Testing Environment	Binary-compatible Family	Portability Environment	Indicator of Compliance	Compliance Details
			None.	Select from this list Test Report from Test Suite	Test Suite: Test Report:
			None.	Select from this list Test Report from Test Suite	Test Suite: Test Report:
			None.	Select from this list Test Report from Test Suite	Test Suite: Test Report:
			None.	Select from this list Test Report from Test Suite	Test Suite: Test Report:
			None.	Select from this list Test Report from Test Suite	Test Suite: Test Report:

Temporary Waivers

1.1 Language Mappings

Question 1: Which language mappings does the product support?

Response

Mapping	Supported
C++
Yes   No
Java
Yes   No

Rationale

A product registered as conformant to the CORBA 2.3 Product Standard must offer one or both of the following language mappings of OMG IDL which are aligned with CORBA 2.3. The reference documents may be found at the OMG document server URL.

• C++    formal/99-07-41
• Java   formal/99-07-53

Reference

The Open Group CORBA 2.3 Product Standard.

1.2 Product Profile

Question 2: Which of the following optional parts of the CORBA 2.3 Technical Standard does the product support?

Response

Option	Supported
DCE/ESIOP
Yes   No
COM/CORBA
Yes   No
Interceptors
Yes   No
Any specific object facilities or services
Yes   No

Rationale

This Product Standard does not require inclusion of the following components of the specification:

• DCE/ESIOP (chapter 16)
• COM/CORBA interworking functionality (chapters 17,18,19,20)
• Interceptors (chapter 21)
• Any specific object facilities or services

Reference

Common Object Request Broker Architecture (CORBA), Version 2.3, Chapter references as in Rationale.

1.3 Policy Domains

Question 3: Is management of Policy Domains supported?

Response

Yes   No

Rationale

Implementation of Management of Policy Domains is not required.

Reference

Common Object Request Broker Architecture (CORBA), Version 2.3, Section 4.10.

1.4 Pragmas

Question 4: Does the product require interface-specific pragmas to precede an Interface body?

Response

Yes   No

Rationale

Some implementations may require interface-specific pragmas to precede the interface body.

Reference

Common Object Request Broker Architecture (CORBA), Version 2.3, Section 3.7.3 Interface Body.

Question 5: Does the product require interface-specific pragmas to precede an operation declaration?

Response

Yes   No

Rationale

Some implementations may require interface-specific pragmas to immediately precede the affected operation declaration.

Reference

Common Object Request Broker Architecture (CORBA), Version 2.3, Section 3.12 Operation Declaration

1.5 Name Space

Question 6: Does the product use the period character to partition the name space?

Response

Not Applicable Yes No

Rationale

The run-time system guarantees to make the value (if any) associated with each <string_literal> in the client's context available to the object implementation when the request is delivered. The ORB and/or object is free to use information in this request context during request resolution and performance. Implementations are allowed to use the period character (.) for apportioning name space.

Reference

Common Object Request Broker Architecture (CORBA), Version 2.3, Section 3.12.4 Context Expressions.

1.6 Binding of Object Reference

Question 7: What is the effect of invoking get_policy prior to the object reference being bound?

Response

Effect	Yes or No
Raise system exception BAD_INV_ORDER	Yes   No
Attempt a binding then return the effective Policy	Yes   No
Return a specified value for that PolicyType which may be subject to change once a binding is performed	Yes   No

If a specified value is returned enter that value in the box below, or enter "Not Applicable".

Rationale

If get_policy is invoked prior to the object reference being bound, the returned effective Policy is implementation dependent. In that situation, a compliant implementation may do any of the following:

• raise the system exception BAD_INV_ORDER
• return some value for that PolicyType which may be subject to change once a binding is performed
• attempt a binding and then return the effective Policy. Note that if the effective Policy may change from invocation to invocation due to transparent rebinding.

This information is of interest to those porting pre-existing Corba applications to the 2.3 platform.

Reference

Common Object Request Broker Architecture (CORBA), Version 2.3, Section 4.3.7, Getting Policy Associated with an Object

1.7 POA

Question 8: Does the POA support the RETAIN policy?

Response

Option	Used
USE_DEFAULT_SERVANT policy	Yes   No
USE_SERVANT_MANAGER policy	Yes   No

Rationale

If the POA supports the RETAIN policy, it maintains a map, labeled Active Object Map, that associates Object Ids with active servants, each association constituting an active object. If the POA has the USE_DEFAULT_SERVANT policy, a default servant may be registered with the POA. Alternatively, if the POA has the USE_SERVANT_MANAGER policy, a user-written servant manager may be registered with the POA. This information is of interest to those porting pre-existing CORBA applications to the CORBA Version 2.3 platform.

Reference

Common Object Request Broker Architecture (CORBA), Version 2.3, Section 11.2.2, Model Architecture

Question 9: What is the implementation limit for the number of requests received?

Response

Enter a value below.

Rationale

The number of requests that can be received and/or queued is an implementation limit. This information is of interest to those porting pre-existing CORBA applications to the CORBA Version 2.3 platform.

Reference

Common Object Request Broker Architecture (CORBA), Version 2.3, Section 11.3.2.1, Processing States (Active State)

Question 10: Does the implementation support both _non_existent and _not_existent in GIOP?

Response

Option	Supported
_non_existent	Yes   No
_not_existent	Yes   No

Rationale

The correct operation name to use for GIOP 1.0 and 1.1 is _non_existent. Due to a typographical error in CORBA 2.0, 2.1, and 2.2, some legacy implementations of GIOP 1.0 and 1.1 respond to the operation name _not_existent. For maximum interoperability with such legacy implementations, new implementations of GIOP 1.0 and 1.1 may wish to respond to both operation names. This information is of interest to those porting pre-existing CORBA applications to the CORBA Version 2.3 platform.

Reference

Common Object Request Broker Architecture (CORBA), Version 2.3, Section 15.4.2.1 Request Header

Question 11: Does the implementation support reference counting?

Response

Yes   No

Rationale

Portable memory management of servants requires an exact specification of when and how a servant may be deleted. This specification supports but does not require reference counting:

• When reference counting is used, the implementation of _remove_ref is assumed to delete the servant when its reference count drops to zero. The POA ensures that a servant will not be deleted while invocations are currently outstanding on that servant by maintaining a reference to the servant until the invocations have completed. For example, the POA may increment the reference count of the servant before invoking the implementation (but after preinvoke and decrement the reference count after the invocation (but before postinvoke.
• If reference counting is not used, some application code must explicitly call delete on a heap-allocated servant for that servant's memory to be reclaimed. Beware that explicit deletion of a servant will cause memory access violations if that servant is still in use by some other part of the application. For example, if the same servant instance was obtained from POA::referenec_to_servant or POA::id_to_servant (perhaps in another thread), the caller that obtained the servant instance may still be using it. Also, explicit deletion may cause problems if the same servant instance is registered in multiple POAs.

This information is of interest to those porting pre-existing Corba applications to the 2.3 platform.

Reference

C++ Language Mapping Specification June 1999, C++ 1.36.4 Servant Memory Management Considerations.

1.8 IDL-to-C++ Translator

Question 12: For which target environment can the implementation's IDL-to-C++ translator provide a mapping for module?

Response

Option	Supported
namespace is upported: namespace and nested classes are not supported	Not Applicable Yes No
namespace is not supported, nested classes are supported: Module is mapped to C++ classes	Not Applicable Yes No
namespace and nested classes are not supported: Module is mapped like C mapping	Not Applicable Yes No

Rationale

If the target environment does not support the namespace construct but does support nested classes, then a module should be mapped to a C++ class. If the environment does not support nested classes, then the mapping for modules should be the same as for the CORBA C mapping (concatenating identifiers using an underscore ("_") character as the separator). Note that module constants map to file-scope constants on systems that support namespaces and class-scope constants on systems that map modules to classes.

Reference

C++ Language Mapping Specification June 1999 C++ 1.18.1 Abstract Interface Base 1.42.1 Without Namespaces

Question 13: For which exception handling environments can the implementation's IDL-to-C++ translator provide a mapping?

Response

Option	Supported
Real C++ exception handling is supported	Not Applicable Yes No
Real C++ exception handling is not supported	Not Applicable Yes No

Rationale

For those C++ environments that do not support real C++ exception handling, referred to here as non-exception handling (non_EH) C++ environments, an Environment parameter passed to each operation is used to convey exception information to the caller.

Reference

C++ Language Mapping Specification June 1999 C++ 1.18.1 Abstract Interface Base 1.42.1 Without Exception Handling