semi合集-English.pdf - 第2673页
SEMI E96-1101 © SEMI 1999 , 2001 13 Boolean query services should rarely rais e an exception unless conditio ns are such that neit her a true or false retu rn value can be determined. 6.4.5 User-defined exceptions can be…
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.
SEMI E96-1101 © SEMI 1999, 2001 14
6.5.5.2 The event header is constructed by the supplier
of the event and is used by an Event Notification
System (ENS) to route the event to any consumer
registering interest in the event. Note that the structure
of the header may be specific to a particular ENS. The
body of the event is constructed by the event supplier
and is intended for use by the event consumer.
Consumers of events express interest in an event type
by passing the subject name and associated filter data
along to the ENS. The ENS returns an original
connection, called an event channel, to the consumer.
6.5.5.3 Name-value pairs are one mechanism that
should be used to define data either in the header or
body. Specific information within the body varies
according to event type; issues such as allocation are
implementation dependent.
6.5.6 Subject String
6.5.6.1 The event subject string should be defined as a
multi-level hierarchy to assist in event classification
and filtering. The levels designate the CIM Framework
issuing the event component, the issuing interface
within that component, and the event type. Each level
should be delimited by a special character (e.g., a
forward slash: “/”). An example of this syntax is
/RecipeManagement/MachineRecipe/ParameterChanged.
6.5.7 Filter Data and News
6.5.7.1 Filter data are attribute names, values, and
operators that are specified by the consumer and are
used by the filter subsystem to further qualify an event.
News consists of additional attributes and values that
are received by the consumer but not used in the
filtering process and thus are not specified by the
consumer. The consumer specifies the attributes,
values, and operators upon which the event data is
filtered. The actual filtering is performed after the
supplier sends an event but prior to the consumer
receiving the event. The filterable data should be well
known and standardized. News may be used by the
consumer to further filter the event, but the attributes
and values are not standardized. Additionally, news
may be used to convey the identity of the object
generating the event to any consumer of the event.
6.5.7.2 An Event Broker is required to support
subscription to an event channel that has the specified
subject and supports filtering. The actual filtering
mechanism is an implementation dependency. Filter
data is passed to the Event Broker by the consumer to
qualify the particular events that the consumer is
interested in receiving. The filter data specifies
filterable items in which the consumer is interested plus
operators and operands to perform the filtering. The
filtering sub-system should use the filter data to ensure
that a specific event is passed to the consumer. The
interface is simple and does not try to construct
advanced logic to build the filter. The results of the
filtering are anded together, such that the passed event
should meet all of the filter criteria. The need to
specify logical operators (e.g., “or”) on the filter criteria
or the use of query languages should be evaluated.
Extensions to the filter structures would be required to
support these additional capabilities.
NOTE 2: The location of the filtering subsystem is an
implementation detail.
6.6 Distributed Transactions
6.6.1 Many operations defined in the CIM Framework
are related to one another in complex ways that require
multiple operations to be treated as a single unit of
work. For example, grouping operations are combined
with the ability to make an explicit decision to commit
the aggregation of changes, or to abort all of the opera-
tions and return to the prior state. These grouping of
operations are consistent with the familiar concept of a
transaction (most commonly encountered in the context
of database management systems). CIM Framework
objects should be capable of participating in trans-
actions as described below. However, the choice of how
an object participates is implementation specific. For
example, the implementer chooses the implementation
technology and whether a change in object state is
recoverable (that is, whether a change in state can be
rolled back).
6.6.2 A transaction is a contract between two or more
objects to perform some action based upon one or more
requests in some context and having the ACID
properties as follows:
6
• Atomicity –– State changes are atomic; either all
happen or none happen. These changes include
database changes, messages and events.
• Consistency –– A correct transformation of state.
Actions taken as a group do not violate any of the
integrity constraints associated with the state.
• Isolation –– Even though transactions execute
concurrently, it appears to each transaction T that
others executed either before T or after T, but not
both.
• Durability –– Once a transaction completes
successfully (commits), its changes to state survive
failures.
6.6.3 For example, consider a lot that starts processing
in a piece of equipment. The states of the lot and the
6 J. Gray, Transaction Processing Concepts and Techniques, Morgan
Kaufmann Publishers/Harcourt Brace and Co., 6277 Sea Harbor Dr.,
Orlando, FL, 1993.