semi合集-English.pdf - 第2665页
SEMI E96-1101 © SEMI 1999 , 2001 5 5.2.15 conformi ng implement ation — an implementation that sati sfies all relevan t specified conform a nce requiremen ts. 5.2.16 event — an as ynchr onou s messa ge deno ting t he occ…
SEMI E96-1101 © SEMI 1999, 2001 4
3.5.2 Internationalization are intended to be addressed
in future revisions of this guide.
3.6 Object Properties
3.6.1 Object properties refers to a technique that allows
additional attributes (data) to be dynamically associated
with an object without changing the interfaces of the
objects to which the properties are attached. This can be
used as a convenient dynamic extensibility mechanism
that may be considered in future CIM Framework
specifications.
3.6.2 Object properties are intended to be addressed in
future revisions of this guide.
3.7 Object Collections and Queries
3.7.1 Object collections and queries allow flexible
access to aggregate data for a group of objects. This
capability may be a candidate to replace the limited
operations for collections found in the component
manager interface.
3.7.2 Object collections and queries are intended to be
addressed in future revisions of this guide.
4 Referenced Standard
4.1 SEMI Standard
SEMI E81 — Provisional Specification for CIM
Framework Domain Architecture
NOTE 1: As listed or revised, all documents cited shall be the
latest publications of adopted standards.
5 Terminology
5.1 Abbreviations and Acronyms
5.1.1 ACID — Atomicity Consistency Isolation
Durability
5.1.2 CIM — Computer Integrated Manufacturing
5.1.3 ECA — Event-Condition-Action (rule)
5.1.4 ECAA — Event-Condition-Action-Alternative
Action (rule)
5.1.5 ENS — Event Notification System
5.1.6 ERP — Enterprise Resource Planning
5.1.7 GUI — Graphical User Interface
5.1.8 MES — Manufacturing Execution System
5.1.9 ODL — Object Definition Language
5.1.10 OMA — Object Management Architecture
5.1.11 OTS — Object Transaction Service
5.2 Definitions
5.2.1 application — 1. one or more programs
consisting of a collection of interoperating objects
which provide domain specific functionality to an end
user or other applications. 2. functionality provided by
one or more programs consisting of a collection of
interoperating objects.
5.2.2 application interface — the interface provided by
an application or application program.
5.2.3 application object — an object implementing an
application interface.
5.2.4 architecture — the structure of the components
of a program/system, their interrelationships, and
principles and guidelines governing their design and
evolution over time.
5.2.5 attribute — an identifiable association between
an object and a value. An attribute may have functions
to set and retrieve its value.
5.2.6 behavior — the effects of performing a requested
service, including its results (e.g., changes in the state
of an object).
5.2.7 binding — a specific choice of platform
technologies and other implementation-specific criteria.
5.2.8 class — the shared common structure and
common behavior of a set of object implementations.
5.2.9 client — an object that uses the services of
another object by sending messages to it or referencing
its state.
5.2.10 collection — an object containing references to
(collections of) other objects with services for
managing them and providing access to them as a
related group of objects.
5.2.11 component — a reusable package of
encapsulated objects and/or other components with
well-specified, published interfaces. The component is
the element of standardization and substitutability for
the CIM Framework.
5.2.12 Computer Integrated Manufacturing — an
approach that leverages the information handling
capability of computers to manage manufacturing
information and support or automate the execution of
manufacturing operations.
5.2.13 conformance — adherence to a standard or
specification in the implementation of a product,
process, or service.
5.2.14 conformance requirement — identification in
the specification of behavior and/or capabilities
required by an implementation for it to conform to that
specification.
SEMI E96-1101 © SEMI 1999, 20015
5.2.15 conforming implementation — an
implementation that satisfies all relevant specified
conformance requirements.
5.2.16 event — an asynchronous message denoting the
occurrence of some incident of importance. For
example, state change or new object created.
5.2.17 event channel — the intermediate object that
forwards published events to interested subscribers.
5.2.18 exception — an infrastructure mechanism used
to notify a calling client of an operation that an unusual
condition occurred in carrying out the operation.
5.2.19 extensibility — the ability to extend or
specialize existing components and add new object
classes or components while preserving architectural
integrity and component conformance to standards.
5.2.20 framework — a collection of classes or
components that provide a set of interoperable services
and functionality for a particular domain.
5.2.21 implementation — the internal view of a class,
object or module, including any non-public behavior.
The specific code and functionality that implements an
interface.
5.2.22 implementation conformance statement — a
statement made by the supplier of an implementation or
system claiming to conform to one or more
specifications and stating which capabilities have been
implemented. It specifically includes the relevant
optional capabilities and limits.
5.2.23 infrastructure — the services, facilities, and
communications mechanisms that support the collabor-
ation between and lifecycle of distributed objects.
5.2.24 inheritance — the ability to derive new classes,
types or interfaces from existing classes, types or
interfaces. For example, a derived class (“subclass”)
inherits the instance variables and methods of the base
class (“superclass”) and may add new instance
variables and methods. In the CIM Framework,
inheritance applies to interfaces and their specification
of operations rather than implementations of classes.
5.2.25 instance — a software entity that has state,
behavior and identity. The terms instance and object are
interchangeable. An object is an instance of an interface
if it provides the operations, signatures, and semantics
specified by that interface. An object is an instance of
an implementation if its behavior is provided by that
implementation.
5.2.26 interface — the external view of a class, object,
or module that emphasizes its abstraction while hiding
its structure and internal behavior. An interface
definition ideally includes the semantics of attributes
and operations.
5.2.27 interoperability — the ability for two
applications or the parts of an application to cooperate.
In the CIM Framework, interoperability requires that
application components be able to support specified
relationships, share data, invoke each others’ behavior
(operations), return exceptions, and exchange events.
5.2.28 lifecycle — the life of an object, including
creation, deletion, copy, and equivalence.
5.2.29 message in object oriented systems a
message is the means by which a client object invokes
the behavior specified by an operation of a server
object.
5.2.30 message bus — a software infrastructure that
provides distributed communication between objects in
component implementations. It can refer to an Object
Request Broker, Microsoft DCOM, Java Remote
Method Invocation or other infrastructure for conveying
messages between objects.
5.2.31 name-value pair — a data structure that
associates a name with an arbitrary value, typically
used as an extensibility mechanism for conveying
information by name-based retrieval.
5.2.32 namespace — a namespace is a bounded
collection of names with a constraint to ensure that each
name is unique within the collection.
5.2.33 object — a software entity that has state,
behavior, and identity. The terms instance and object
are interchangeable. An object is an instance of an
interface if it provides the operations, signatures, and
semantics specified by that interface. An object is an
instance of an implementation if its behavior is
provided by that implementation.
5.2.34 object services — interfaces for general services
that are likely to be used in any program based on
distributed objects.
5.2.35 operation — an operation is a specification en-
tity, identified by an operation identifier, that denotes a
service that can be requested. An operation has a sig-
nature that describes the legitimate values of request
parameters and returned results, including any
exceptions.
5.2.36 persistent object — an object that can survive
the process or thread that created it.
5.2.37 productive entity productive entity is an
abstraction of a physical unit, which is involved in any
way in a production process (e.g. production or
supporting equipment). A productive entity has its own
SEMI E96-1101 © SEMI 1999, 2001 6
internal logic and provides a software interface to
access this logic
5.2.38 query a message sent to a server (e.g. the
productive entity) by a client interested in some
information from the server (state of the productive
entity). A query may or may not have arguments and it
always has an answer. The semantics of a query is that
some information from the server is returned, but the
query cannot effect any change to the state of the
server.
5.2.39 service a function provided by a service
provider that is performed through an operation
specified by the provider.
5.2.40 service provider, server an object providing
services to other objects as specified by its published
operations.
5.2.41 signature — a signature is the name,
parameters, return values, and exceptions for a specific
operation.
5.2.42 substitutability — the ability to replace a given
component from one supplier with a functionally
equivalent component from another supplier without
impacting the other components or its clients in the
system.
5.2.43 trader service — a collection of names with
associated properties of features for each name and
methods for manipulating and inspection that
collection.
5.2.44 type — a declaration that describes the common
properties and behavior for a collection of objects.
Types classify objects according to a common inter-
face; classes classify objects according to a common
implementation.
6 Technical Architecture Guidance
6.1 The computing infrastructure provides the distrib-
uted computing environment for CIM Framework
applications. This infrastructure includes the operating
system, networking and communications, data storage
and access, user interface and presentation services,
event distribution, systems management, and many
other elements. Of these many infrastructure elements,
a guide for technical architecture specifies a small
subset of key services that need to be standardized in
order to facilitate and streamline system integration
between conformant CIM Framework implementations.
6.2 The CIM Framework relies on publicly available
specifications to define the use of infrastructure
services wherever such published specifications exist.
The largest single source for openly defined specifica-
tions for distributed object services is the Object Man-
agement Architecture.
5
Reference to this guide does not
imply that CIM Framework conformant implement-
ations should implement the referenced services. The
implementations that realize these infrastructure
technologies are outside the scope of this guide. The
technology choices made by implementers should be
kept transparent to the CIM Framework to the greatest
extent possible.
6.3 Distributed Object Communication
6.3.1 The CIM Framework documents assume the use
of software infrastructure to provide distributed com-
munication between objects in an implementation. The
acronym ORB was originated by the OMG to describe
its distributed object communication infrastructure, but
is sometimes used in a more general sense. In this doc-
ument ORB is used only to refer to the OMG specified
technology and the more general term “message bus” is
used for the diverse class of distributed communication
mechanisms for communication between objects. The
message bus is used to allow objects to make requests
and receive responses from other objects. An object can
communicate through the message bus with objects that
are local or remote. Location transparency allows the
object to remain ignorant of the actual location of the
object with which it communicates.
6.3.2 A primary criterion for a message bus imple-
mentation is its ability to deliver all messages specified
by the interfaces of the CIM Framework components.
To accomplish this, the message bus should provide the
ability to support or map a specified interface, including
its inherited features, data types, operations, object
references, and exceptions to and from runtime
marshaled transport formats.
6.3.3 Alternate message bus implementation technolo-
gies are supported by the CIM Framework by mapping
the OMG IDL for the CIM Framework interfaces into a
specific message bus implementation. The Common
Object Request Broker: Architecture and Specification
4
contains sections that define this mapping from
CORBA to COM and from CORBA to OLE Automa-
tion. These sections, called the “Interworking Architec-
ture,” cover detailed rules for mapping OMG IDL,
types, and exceptions to compatible interfaces in COM
and OLE Automation.
6.3.4 From a high level perspective, the DCOM and
CORBA message buses are comparable. The DCOM
capabilities are roughly equivalent to those of an ORB.
However, with a lower level analysis, differences show
up in data types, inheritance, object identity, and the
handling of exceptions. The CORBA Interworking
5 Object Management Group. The Object Management Architecture
Guide, Revision 3.0, John Wiley and Sons, New York NY, 1995.