semi合集-English.pdf - 第2671页
SEMI E96-1101 © SEMI 1999 , 2001 11 6.3.24 Use of OM G IDL Module Packa ging Con- structs 6.3.24.1 All IDL state ments included as part of the specifi cation of S EMI E81 shou ld be contained wi thin one or m ore CIM Fra…
SEMI E96-1101 © SEMI 1999, 2001 10
Variants : None
IDL
module ControlStateModule {
// Type Definitions
enum ControlState {OFFLINE, LOCAL,
REMOTE);
interface ControlState {
// Queries
ControlState getControlState()
raises (EqBasicTypesModule::
CommunicationFailure);
// Commands
void changeControlStateToOffline()
raises (EqBasicTypesModule::
CommunicationFailure);
void changeControlStateToLocal()
raises (EqBasicTypesModule::
CommunicationFailure);
void changeControlStateToRemote()
raises (EqBasicTypesModule::
CommunicationFailure);
};
};
6.3.19.2.8 The control state aspect can post the
following events:
ControlStateChangedToLocal
ControlStateChangedToRemote
controlStateChangedToOffline
6.3.20 Interface Composition Mapping
6.3.20.1 The DCOM interfaces do not support multi-
ple inheritance. When multiple inheritance is used to
extend functionality, the mapping is not very difficult.
When multiple inheritance is used to “mix in” orthogo-
nal behavior the mapping is more difficult. The CIM
Framework interfaces that only use single inheritance
provide the most reliable mapping. Interfaces that use
multiple inheritance should follow the detailed mapping
rules and ordering provided in the CORBA
Interworking Architecture.
6.3.20.2 OLE Automation also has problems directly
supporting the multiple inheritance of CORBA. The
CORBA Interworking Architecture
4
provides detailed
mapping rules for making the conversion where
multiple inheritance is used.
6.3.21 Identity Mapping
6.3.21.1 CORBA and DCOM/OLE Automation have
different notions of what object identity means.
CORBA defines an object as a combination of the state
and a set of operations that explicitly define the
instance. An object reference is defined as a name that
reliably and consistently denotes an instantiated object.
A CORBA object exists until it is destroyed; its
lifecycle is controlled by the server.
6.3.21.2 DCOM does not provide the same mechanism
for identifying a particular object. DCOM objects are
usually created when used and their state does not
persist as an object instance. DCOM objects exist while
they are referenced; their lifecycle is controlled by the
client. This is true of OLE Automation objects as well.
6.3.21.3 The CORBA Interworking Architecture
provides mapping solutions for managing the object
lifecycle. The lifecycle issues should be minimized with
the CIM Framework use of component managers to
control object lifecycles. The implementation of
DCOM lifecycle mapping should be encapsulated in the
component manager.
6.3.22 Naming
6.3.22.1 As a mechanism to support initialization
between collaborating components, the name of each
component manager should be registered in a publicly
available namespace along with the object reference for
the component manager. The same name may be reused
unambiguously as long as all occurrences belong to
distinct namespaces. Other objects should be able to
obtain a handle (object reference) to each component
manager by utilizing the namespace through the
operations of a naming service. A trader service may
also be used to perform lookup of component managers
and other objects based on well documented search
criteria. Additional objects may also be registered in the
namespace or trader as appropriate. The component
manager serves as the namespace for the objects it
manages, providing object references for named
objects. Implementations should provide documentation
on how to obtain available object references in either
the namespace or the trader.
6.3.23 Memory Management
6.3.23.1 ORB implementations’ memory allocation
and deallocation services should handle all three types
of OMG IDL parameter passing:
• in –– Memory is caller-allocated and read-only.
The caller is responsible for memory deallocation.
• out –– Memory deallocation depends on the
specific usage of the argument.
• inout –– Memory allocation and deallocation
depend on the specific usage of the argument.
6.3.23.2 The CIM Framework uses only the in para-
meter passing mechanism. Within operations that have
had objects passed by reference, any modification of
the object occurs by using the in parameter as a refer-
ence. Supplier provided extensions to the CIM Frame-
work that use either the out or inout parameter passing
mechanism should document the caller and callee
responsibilities with respect to memory allocation and
deallocation.
SEMI E96-1101 © SEMI 1999, 200111
6.3.24 Use of OMG IDL Module Packaging Con-
structs
6.3.24.1 All IDL statements included as part of the
specification of SEMI E81 should be contained within
one or more CIM Framework defined modules.
6.3.24.2 CIMFW Module Conventions
6.3.24.2.1 Each CIM Framework sub-document that
specifies IDL declarations should provide a full listing
of the IDL statements in a compilable IDL file. This file
may be presented as an appendix to the specification
prior to final adoption and preparation for distribution
with the standard. The IDL file should include module
statements to enclose all IDL declarations for that
specification.
6.3.24.2.2 IDL files (or appendices) should begin with
a comment identifying the correct name of the file that
contains the enclosed IDL specification. The following
hypothetical example illustrates the form of this
comment.
//File: CIMFactoryLabor.idl
//Part of the CIM Framework for the
Factory Labor Component
6.3.24.2.3 Every IDL appendix should contain the
following statement identifying the top-level module
that contains all CIM Framework declarations.
module CIMFW{
...
};
6.3.24.3 Lower Level Modules within the CIM
Framework Module
6.3.24.3.1 The CIM Framework module should enclose
second level modules that further package each
partition of the CIM Framework specification as
defined in SEMI E81. All IDL declarations should thus
be scoped, first, to the CIM Framework, and second, to
the specific component of the framework. The fol-
lowing example illustrates the positioning of elements
of the Factory Labor component within a component
module.
module CIMFW{
module FactoryLabor{
typedef ..., etc.
};
};
6.3.24.3.2 Subsequent decomposition of CIM Frame-
work specifications into a third level of module contain-
ment may be necessary in some places, but should be
avoided where possible to keep fully qualified names
from getting to an unworkable length.
6.3.24.4 Conventions for CIM Framework Dependen-
cies
6.3.24.4.1 Each CIM Framework IDL file should
include explicit statements identifying any other files in
the CIM Framework specification set that contain mod-
ules that are referenced. These statements should be in
the form of #include statements. In order to avoid
circular references among related modules, a specifi-
cation may need to partition a module into more than
one file and include parts of the module at different
points in the referencing file. This structure of IDL files
is dependent on the specific implementation and which
parts of the CIM Framework it implements and may be
adjusted as needed to achieve successful compiles. The
IDL files distributed with the standard should suggest a
file structure to achieve a successful compile, but
should not indicate that the file structure is specified as
a part of the standard. The following example illustrates
an include statement.
#include <CIMGlobal.idl>
module CIMFW{ ...
6.3.24.4.2 All references to elements of separate mod-
ules will then need to be fully qualified with the module
scoping. For example, to reference a type defined in
the CIMGlobal module, the reference should take a
form similar to the following hypothetical example:
#include <CIMGlobal.idl>
module CIMFW{
module FactoryLabor{ ...
Global::MachineSequence
assignedMachines ()
raises
(Global::FrameworkErrorSignal);
};
};
6.3.24.4.3 Fully qualified names may also be
automatically generated if the target programming
language compiler supports the “namespace” concepts.
For example, the C++ standard uses namespace and
Java uses package to support namespaces.
6.3.24.5 Guard Statements
6.3.24.5.1 To avoid the possibility of the same CIM
Framework file being included more than once and thus
causing multiple definition errors, each module should
be preceded by the following type of guard statement.
SEMI E96-1101 © SEMI 1999, 2001 12
#ifndef _CIM_FACTORY_LABOR_IDL_
#define _CIM_FACTORY_LABOR_IDL_
module ...
};
#endif // _CIM_FACTORY_LABOR_IDL_
6.3.24.5.2 The guard name should be designated by the
string that begins and ends with an underscore and
includes an all caps version of the filename with
embedded underscores to separate the parts of the
name. The guard statement should be documented for
each module.
6.3.24.6 Naming Modules and IDL Files
6.3.24.6.1 All Module names for CIM Framework
specifications are scoped within the CIMFW module
and need not use redundant prefixing of the name with
CIMFW. The names should be derived as closely as
possible from the name of the CIM Framework
specification they represent.
6.3.24.6.2 All Names should be composed of one or
more words, abbreviations or acronyms concatenated
together with capital letters used as delimiters between
parts.
6.3.24.6.3 Names should be kept as short as possible
while still providing understandable semantic
associations for the subject module.
6.3.24.6.4 IDL File names should be based on the
second level module contained within the CIMFW
module.
6.4 Exception Declarations
6.4.1 Exceptions provide an alternative return
mechanism for operations. When performing a normal
return, control is returned to the point of invocation and
the provided return values and output parameters are
valid. Abnormal operation results raise an exception,
which causes control to return to the defined exception
handler and breaks the flow of control. Any data
defined as part of the exception and provided by the
called operation is valid and available to the exception
handler. When an exception is raised, normal output
parameters defined in the operation signature are not
valid and are not available in the exception handler.
6.4.2 Exceptions are not communicated as an oper-
ation return code. An exception signifies that the post-
conditions for successful operation completion have not
been satisfied. If, on the other hand, the operation
merely needs to communicate which one of multiple
post-conditions were met, then the operation should
provide this information in a return code or return
structure as part of the normal operation completion.
6.4.3 Exception declarations in OMG IDL follow a C
struct-like data structure with the keyword exception
taking the place of struct. It contains attributes that can
be used to pass information about an exception
condition to a service requester. An exception is
declared with an identifier (ExceptionNameSignal, the
exception name), which is accessible as a value when
the exception is raised, allowing the client to determine
which exception has been received. Data values
associated with the exception, if declared, are
accessible to the client. The keyword raises is used in
the operation definition to specify that a user-defined
exception may be raised (or thrown in implementation
terminology). The CIM Framework specifications
assume that an operation may raise a CORBA-defined
standard system exception, thus these exceptions are
not specified.
6.4.4 The following conventions are used when
defining exceptions:
Exceptions are not reserved for system or
programming errors or failures, but should be included
for any abnormal application behavior in the called
service. This is consistent with CORBA usage of
exceptions for application errors.
Exception descriptions are shown as OMG IDL
comments similar to descriptions for services.
Return values should, if necessary, be implemented
as fields in the exception definition.
All state transition services (e.g., makeXXX ser-
vices) should include the InvalidStateTransition-Signal
exception in their list of raised exceptions.
Services that perform a “find” or “lookup” function
raise an appropriate <ObjectType> NotFound-Signal
exception: a null return value is not an appropriate
response. However, services that return a collection of
objects do not raise an exception but simply return an
empty collection.
Services that perform “add” functions raise a
<ObjectType>DuplicateSignal exception for the case
where the object to be added is already in the target
collection or logical set. The exception includes a field
containing a reference to the currently existing object.
Services that perform “remove” functions raise a
<ObjectType>NotAssignedSignal exception for the
case when the given object is not in the collection it
was to be removed from or <ObjectType>
RemovalFailedSignal exception if the object could not
be removed.