semi合集-English.pdf - 第2672页
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 na me sho uld be designate d by the string th at be…
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.
SEMI E96-1101 © SEMI 1999, 200113
Boolean query services should rarely raise an
exception unless conditions are such that neither a true
or false return value can be determined.
6.4.5 User-defined exceptions can be defined for any
operation specified in IDL. Only user-defined
exceptions that are defined and listed in the raises
clause of an operation should be thrown. Interface-
defined or other standard system exceptions may be
thrown without using a raises clause on an operation.
The data contained in the user exception should help
the caller interpret and deal with the exception. Specific
data can be defined for each user exception. Any
additional information that assists in debugging
situations should be sent to a tracing or logging facility.
6.4.6 Operations should throw standard system
exceptions when an error condition clearly matches the
defined exception. This ability should be used
judiciously as the receiver of the exception may not be
able to distinguish between a system-thrown or user-
thrown exception. If a system exception does not
clearly fit the situation at hand, then a user exception
should be defined. Use of user-defined exceptions is
part of the binding that should be considered for
interoperability and substitutability.
6.4.7 The mapping defined for exceptions should
support both the system exceptions and user exceptions.
The CORBA model uses the concept of exceptions
being raised to report error information. There should
be exception specific data associated with the
exception. The DCOM model provides error
information by returning an HRESULT type. There is
no facility for returning user-defined exception data.
6.4.8 The CORBA Interworking Architecture provides
a mapping for the CORBA System Exceptions to the
DCOM HRESULT values. The additional exception
information for User Exceptions can be returned in an
exception structure and added as another parameter to
methods that include the raises keyword. The OLE
Automation mapping provides for the use of a Pseudo-
Automation Interface called a pseudo-exception. This is
included in the interface as an additional out parameter.
6.4.9 The mapping of exceptions from CORBA to
DCOM is very complex and requires an added
parameter on many of the interfaces. The complete
mapping rules are defined in the CORBA Interworking
Architecture.
6.5 Event Specification
6.5.1 This guide uses a publish/subscribe model of
events. Published events are sent to subscribers of the
event in an asynchronous manner. The identity and
quantity of subscribers are not known by the publisher
of an event. The publisher is also known as the
“supplier” and the subscriber known as the “consumer”
of the event. Although the receipt of an event can alter
the flow of control in the consumer, they should
typically be used primarily as an information broadcast
mechanism. Direct operation requests to another object
should be used when affecting changes to critical flow
of control to ensure message receipt by the intended
recipient.
6.5.2 This guide suggests the use of an event delivery
mechanism called “event channels.” Event channels can
provide a coarse grain filtering capability for events.
Consumers can subscribe to a specific event channel in
order to receive a particular event type. The event
broker specification of this guide extends this event
channel capability by adding features for locating event
channel, registering for event delivery, and filtering the
events of interest to minimize performance penalties
when large numbers of events are present.
6.5.3 This guide supports creating, posting, and
subscribing to events. It also provides the mechanisms
to support subject-based addressing. When a consumer
subscribes to events for a particular subject, it should be
notified whenever an event for the subject is posted by
any supplier.
6.5.4 The event delivery requirements are summarized
as follows:
Suppliers do not know who the consumers of news
events are; therefore, suppliers do not need to get a
“handle” for them.
No response or answer is sent back from the
consumer(s) to the supplier once the post is completed.
Message delivery is based entirely on message
context (subject).
6.5.5 Event Content
6.5.5.1 The specification of event content should have
two parts: a header and a body. The header should
consist of information of a general nature regarding the
event, such as the name of its subject (a subject string
used for identification); an aging factor (for
determining event effectiveness and may be site
specific); priority; and any filtering information
relevant to event delivery at a general level. The event
body should contain: the actual event message; the
original time of the event; and data relevant to filtering
by the consumer of the event. The body should also
contain any information required by the consumer not
used in the filtering process (called “News”). The body
should be extended with object references as required to
facilitate communication with any objects associated
with the event.