semi合集-English.pdf - 第2674页

SEMI E96-1101 © SEMI 1999 , 2001 14 6.5.5.2 T he even t header is constructed by the supplier of the e vent and is used by an Event Notification System (ENS) to route the event to any consum er registering interest in th…

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:

• 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.

SEMI E96-1101 © SEMI 1999, 200115

equipment should change in order to accurately track

the state of the factory. Coordinating the lot and

equipment state changes as a transaction guarantees that

factory state can be recovered accurately.

6.6.4 Transactions are created by a user of a service

(the client) requesting an operation from a provider of a

service (the server). To maintain the ACID properties

of a transaction, the server should be able to return to

the state prior to the request for the operation in the

event of a failure. In this sense, the server should be

recoverable. Failures are either software or hardware

events that prevent the completion of the transaction.

The server is a recoverable server if it is able to main-

tain the ACID properties when faced with a failure.

6.6.5 Transactions should be designed in a manner

such that they do not span a period of interaction with

an external entity such as a person using a GUI or a

piece of equipment. Waiting for the response from an

external entity can result in locks being held for multi-

ple seconds, minutes, or longer. This can adversely

affect other transactions by causing time-outs or dead-

locks. These types of transactions can usually be split

into multiple serially executed transactions with some

small amount of extra revalidation of current states at

succeeding transactions.

6.6.6 Coordinating the completion of transactions may

involve multiple servers and may entail either commit-

ting the successfully completed transaction or rolling

back the unsuccessful transaction. This activity imposes

additional overhead on a system. Suppliers and

consumers should assess the impact of transactions on

system performance during component design and

selection of transactional events.

6.6.7 Transactions may cause physical effects in the

manufacturing system that cannot simply be rolled back

in accordance with the ACID properties. Application

and system designers should include ways to modify

the logical view of the system to match the physical

reality of the manufacturing floor if such a mismatch

occurs.

6.6.8 Transactions can create CIM Framework events

as state changes occur. As the transaction may not be

committed at the point of event creation, the event

should not be visible outside the transaction until the

final commit point. The details of performing this task

are implementation dependent. For example, the event

announcing the completion of a lot at a processing step

should not be published until the processing step

completion transaction is committed. Otherwise, the

event could be published, but the transaction subse-

quently rolled back, creating a system inconsistency.

6.6.9 Transactions should be able to be nested, thus

providing the ability to define transactions within other

transactions. These sub-transactions can generate addi-

tional sub-transactions, thus forming a hierarchy of

transactions. In the spirit of maintaining the ACID

properties, each sub-transaction can issue a commit or

rollback for its piece of work. The results of the sub-

transaction are only available to the parent transaction.

The sub-transactions commit becomes permanent only

after it issues a local commit and all ancestors commit.

If the parent transaction does a rollback, all descendent

transactions are rolled back regardless of any local

commits.

6.6.10 There are two types of transactions widely sup-

ported for distributed object infrastructures. The OMA

support for transactions is described in the OMG’s

Object Transaction Service (OTS). Microsoft provides

support for transactions with its Microsoft Transaction

Server (MTS) product. The OTS closely aligns with

other standards such as The Open Group Distributed

Transaction Processing (DTP) model.

Using industry

standard protocols as a base, the OTS supports inter-

facing with products from the major database suppliers.

Using the provided OTS interfaces and information

about The Open Group standards, non-ORB supplied

database interfaces could be developed to allow for

interoperability with other cooperating transaction

services. MTS also supports transactions with major

database suppliers through use of The Open Group XA

interface. Using the MTS Software Developer Kit,

transaction support can be extended to other resources.

6.6.11 Combining heterogeneous components based on

a combination of OTS and MTS is not straightfor-ward.

Although both rely on the XA interface for dis-tributed

transaction coordination, they are not designed to

operate with each other. Both OTS and MTS hide the

details of transactions from users. This makes either so-

lution very convenient, but makes linking them together

more difficult. For example, suppose a CORBA-based

component adhering to OTS should interact with an

MTS-based component. The scenario calls for the

CORBA based component to use the XA interface to

work with the MTS provided transaction coordinator

(see Gray

for additional information on distributed

transactions). However, in hiding XA complexity, OTS

also hides the ability to readily specify the transaction

coordinator (OTS does this behind the scenes). CIM

Framework component developers and consumers

should determine the relative need for distributed trans-

actions spanning OTS and MTS against the additional

complexity of developing a XA-based mechanism for

combined OTS and MTS transactions.

7 The Open Group, Distributed TP: The XA+ Specification, Version

2, The Open Group, 11 Cambridge Center, Cambridge MA, 1994.