Conformance Requirements

This section identifies the conformance points required for compliant implementations of the CORBA Component model.

The following conformance points are defined:

1. A CORBA COS vendor shall provide the relevant changes to the Lifecycle, Transaction, and Security Services identified in the following Section 1.12.2, ÒChanges to Object Services,Ó on page 1-55.

2. A CORBA ORB vendor need not provide implementations of Components aside from the changes made to the Core to support components. Conversely a CORBA Component vendor need not be a CORBA ORB vendor.

3. A CORBA Component vendor shall provide a conforming implementation of the Basic Level of CORBA Components.

4. A CORBA Component vendor may provide a conforming implementation of the Extended Level of CORBA Components.

5. To be conformant at the Basic level a non-Java product shall implement (at a minimum) the following:

¥ the IDL extensions and generation rules to support the client and server side component model for basic level components.

¥ CIDL. The multiple segment feature of CIDL (Section 2.12, ÒSegment Definition,Ó on page 2-10) need not be supported for basic components. ¥ a container for hosting basic level CORBA components.

¥ the XML deployment descriptors and associated zip files for basic components in the format defined in Section 6.1, ÒIntroduction,Ó on page 6-1.

Such implementations shall work on a CORBA ORB as defined in #1 above. 6. To be conformant at the Basic level a Java product shall implement (at a minimum):

¥ EJB1.1, including support for the EJB 1.1 XML DTD. ¥ the java to IDL mapping, also known as RMI/IIOP.

¥ EJB to IDL mapping as defined in Section 5.3.2, ÒTranslation of CORBA Component requests into EJB requests,Ó on page 5-9.

Such implementations shall work in a CORBA interoperable environment, including interoperable support for IIOP, CORBA transactions and CORBA security.

7. To be conformant at the extended level, a product shall implement (at a minimum) the requirements needed to achieve Basic PLUS:

¥ IDL extensions to support the client and server side component model for extended level components.

¥ A container for hosting extended level CORBA components.

¥ The XML deployment descriptors and associated zip files for basic and enhanced level components in the format defined in Section 6.1, ÒIntroduction,Ó on page 6-1.

Such implementations shall work on a CORBA ORB as defined in #1 above. 8. A CORBA Component vendor may optionally support EJB clients interacting with

CORBA Components, by implementing the IDL to EJB mapping as defined in Section 5.4.2, ÒTranslation of EJB requests into CORBA Component Requests,Ó on page 5-17.

9. This specification includes extensions to IDL, in the form of new keywords and grammar. Although a CORBA ORB vendor need not be a CORBA Component vendor, and vice-versa, it is important to maintain IDL as a single language. To this end, all compliant products of any conformance points above shall be able to parse any valid IDL definitions. However, it is permitted to raise errors, or to ignore, those parts of the grammar that relate to another conformance point.

Conforming implementations as defined above may also implement any additional features of this specification not required by the above conformance points.

1.12.1 A Note on Tools

Component implementations are expected to be supported by tools. It is not possible to define conformance points for tools, since a particular tool may only support part of the component development and deployment life-cycle. Hence a suite of tools may be needed. The Component architecture contains a number of definitions that are relevant to tools, including zip files and XML formats, as well as IDL interfaces for

customization and installation. Although it cannot be enforced, tools are expected to conform to the relevant areas with which they are dealing. For example, a tool that generates implementations for a particular platform is expected to generate XML according to the <implementation> clauses in the DTD (defined in CORBA Core, the Interface Repository chapter).

1.12.2 Changes to Object Services

1.12.2.1 Life Cycle Service

To support the factory design pattern for creating a component instance and to allow the server, rather than a client, to select from a group of functionally equivalent factories based on load or other server-side visible criteria, the following operation is added to the FactoryFinder interface of the CosLifeCycle module:

interface FactoryFinder {

Factory find_factory (in Key factory_key) raises (noFactory); };

};

The parameters of the above operation are as defined by CosLifeCycle with the following clarifications:

¥

The factory_key parameter is a name conforming to the Interoperable Naming Specification (orbos/98-10-11) for stringified names.

¥

The factory_key parameter is used as an input to the find_home_by_name operation on Components::HomeFinder.

¥

The default factory operation on the home is used to obtain a reference which can be narrowed to the CosLifeCycle::GenericFactory type.

1.12.2.2 Transaction Service

The following CORBA transaction service interface is changed to a local interface:

¥

CosTransactions::Current

1.12.2.3 Security Service

The following CORBA Security interfaces are changed to local interfaces:

¥

SecurityLevel1::Current

¥

SecurityLevel2::PrincipalAuthenticator

¥

SecurityLevel2::Credentials

¥

SecurityLevel2::ReceivedCredentials

¥

SecurityLevel2::AuditChannel

¥

SecurityLevel2::AuditDecision

¥

SecurityLevel2::AccessDecision

¥

SecurityLevel2::QOPPolicy

¥

SecurityLevel2::MechanismPolicy

¥

SecurityLevel2::InvocationCredentialsPolicy

¥

SecurityLevel2::EstablishTrustPolicy

¥

SecurityLevel2::DelegationDirectivePolicy

¥

SecurityLevel2::Current

¥

SecurityReplacable::Vault

¥

SecurityReplacable::SecurityContext

¥

SecurityReplacable::ClientSecurityContext

¥

SecurityReplacable::ServerSecurityContext

Note Ð Text in Red is from the Components 1.1 RTF interim report (ptc/2002-08-02).

This chapter describes OMG Component Implementation Definition Language (CIDL) semantics and gives the syntax for OMG CIDL grammatical constructs.

Contents

Note Ð Issue 5499

This chapter contains the following sections.

Section Title Page

ÒOverviewÓ 2-2

ÒLexical ConventionsÓ 2-3

ÒOMG CIDL GrammarÓ 2-3

ÒOMG CIDL SpecificationÓ 2-5

ÒComposition DefinitionÓ 2-6

ÒCatalog Usage DeclarationÓ 2-7

ÒHome Executor DefinitionÓ 2-8

ÒHome Implementation DeclarationÓ 2-9

ÒStorage Home BindingÓ 2-9

2.1 Overview

The OMG Component Implementation Definition Language (CIDL) is a language used to describe the structure and state of component implementations. Component-enable ORB products generate implementation skeletons from CIDL definitions. Component builders extend these skeletons to create complete implementations.

OMG CIDL obeys the same lexical rules as OMG Persistent State Definition Language (PSDL) and OMG IDL, although new keywords are introduced to support concepts specific to component implementation descriptions.

The description of OMG CIDLÕs lexical conventions is presented in Section 2.2, ÒLexical Conventions,Ó on page 2-3. A description of OMG IDL preprocessing is presented in CORBA Core, IDL Syntax and Semantics chapter, Preprocessing section. The scope rules for identifiers in an OMG IDL specification are described in CORBA Core, IDL Syntax and Semantics chapter, CORBA Module section.

The OMG CIDL grammar is an extension of a combination of the OMG PSDL and OMG IDL grammars, with new constructs to define component implementations. OMG CIDL is a declarative language. The grammar is presented in Section 2.3, ÒOMG CIDL Grammar,Ó on page 2-3.

A source file containing specifications written in OMG CIDL must have a Ò.cdlÓ extension.

The description of OMG CIDL grammar uses the same syntax notation that is used to describe OMG IDL in CORBA Core, IDL Syntax and Semantics chapter. For

reference, Table 2-1 lists the symbols used in this format and their meaning.

ÒSegment DefinitionÓ 2-10

ÒSegment Persistence DeclarationÓ 2-11

ÒFacet DeclarationÓ 2-12

ÒFeature Delegation SpecificationÓ 2-12

ÒAbstract Storage Home Delegation SpecificationÓ 2-13

ÒExecutor Delegation SpecificationÓ 2-15

ÒAbstract Spec DeclarationÓ 2-16

ÒProxy Home DeclarationÓ 2-16

Table 2-1 IDL EBNF

Symbol Meaning

::= Is defined to be | Alternatively <text> Nonterminal

In document September 2002 Version 3.0 ptc/ An Adopted Specification of the Object Management Group, Inc. (Page 68-73)