semi合集-English.pdf - 第2666页
SEMI E96-1101 © SEMI 1999 , 2001 6 internal log ic and provides a sof tware interface to access this logic 5.2.38 query a messa ge sent to a server (e.g. the productive entity) by a client interested in so me informati…
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.
SEMI E96-1101 © SEMI 1999, 20017
Architecture
4
(Chapter 15, “Interworking Architecture,”
Chapter 16, “Mapping COM to CORBA,” and Chapter
17, “Mapping OLE Automation to CORBA”) defines
mapping approaches covering:
Interface Mapping,
Interface Composition Mapping, and
Identity Mapping.
6.3.5 These areas should be addressed in order to pro-
vide a mapping between the OMG IDL used to specify
CIM Framework interfaces and the message bus used
for implementation. If the mapping is not specific (i.e.,
can occur in multiple ways) then two implementations
may not necessarily be able to communicate even if
they use the same message bus type. Although the
CORBA Interworking Architecture is specific to
Microsoft technologies, it could provide the foundation
for future interworking mappings.
6.3.6 The current CIM Framework interfaces are
specified in OMG IDL. The interfaces can be directly
compiled and used with any of the available ORB
implementations on the market.
6.3.7 The only way to provide such a direct solution
using Microsoft DCOM would be to create additional
CIM Framework interface specifications in DCOM
MIDL and/or OLE Automation ODL. This would allow
direct support for message bus functionality using
DCOM. For example, the CIM Framework memory
management requirement of “in” for parameter passing
(see Section 6.3.15) would be directly supported by
MIDL and DCOM but since the CORBA exception
model is significantly richer than the DCOM exception
model, mapping CORBA exceptions to COM would
require an additional protocol to be defined for DCOM.
6.3.8 The CORBA Interworking Architecture supports
mapping the current CIM Framework interfaces defined
in OMG IDL to DCOM MIDL or OLE Automation
ODL. This mapping is detailed enough that the map-
ping should always provide the same MIDL/ODL solu-
tion. Even though the current scope does not include
interoperability between implementations on DCOM
and CORBA (see Section 3.2), the issue of mapping the
interface is still the same. This would also provide a
step towards true interoperability using CORBA/
DCOM bridge products that are beginning to become
available.
6.3.9 Microsoft also provides an extension called OLE
Automation. These interfaces are described in Object
Definition Language (ODL). The OLE interfaces can be
invoked dynamically by a client with no compile-time
interface knowledge. The OLE data types are a subset
of the types supported in DCOM, and there is no sup-
port for user-defined constructed types. The mapping
solution differs for the DCOM and the OLE Automa-
tion. OLE Automation does not provide as clean a map-
ping from OMG IDL as DCOM does. This limitation
may not allow some of the interfaces to translate com-
pletely to an OLE Automation implementation. Thus,
component suppliers using an OLE Automation imple-
mentation should explain impact on interfaces that were
not fully supported due to the Automation restrictions.
6.3.10 The CORBA Interworking Architecture covers
mapping issues for the major areas of concern for the
CIM Framework. The areas of primary importance are
the Interface mapping, Interface composition mapping,
Identity mapping, and Exception mapping. The
CORBA Interworking Architecture gives detailed map-
pings for each of these areas and deals with the DCOM
and OLE Automation mappings separately. The follow-
ing five subsections summarize these mapping issues.
6.3.11 Interface Mapping
6.3.11.1 The OMG IDL primitives, constructed data
types, and object references map closely to DCOM. The
inherited CORBA interfaces may be represented as
multiple DCOM interfaces. The CORBA attributes may
be mapped to get and set operations in DCOM
interfaces.
6.3.11.2 The OMG IDL primitives map to OLE
primitives except for special cases. The OLE interfaces
do not support constructed data types and should be
mapped to specially constructed interfaces. CORBA
object references map to OLE Automation interface
pointers. There are difficulties in mapping CORBA
multiple inheritance to OLE Automation interfaces
documented in the CORBA specification.
4
CORBA
attributes may be mapped to get and set operations in
OLE Automation interfaces.
6.3.12 Aspects The total behavior of a piece of a
productive entity in a factory can be viewed as the
union of distinct behaviors. Each such isolated behavior
(or functional area) is called an aspect of the productive
entity.
6.3.12.1 There is great variety in productive entity
behavior. There are generic aspects that are shared by
all or most productive entities (such as recipe
management or process state model or material
tracking) and there are aspects that are specific to one
productive entity type or to a particular productive
entity model. The behavior of each productive entity is
the union of the particular aspects of that productive
entity.
6.3.12.2 Saying that two pieces of productive entities
have a certain aspect does not necessarily mean that
they behave absolutely the same way. There are two