semi合集-English.pdf - 第3676页

SEMI PR8-0703 © SEMI 2003 6 7.1.5 SOAP Bindi ng — The SOAP binding specified in this document shall be HTTP 1.1 in accordance with t he SOAP 1.1 W3C Note. 7.1.6 SOAP Message St yle — Message encoding will be XML docum en…

SEMI PR8-0703 © SEMI 2003 5

Covered in

Section #

Feature Description

Supported By

Interface Definition

Implementation

Required

Data Collection Plans

7.9 The data to be transmitted through the EDA port shall be

defined in a set of named data collection plans.

7.9 Data collection plans shall describe which events, exceptions,

data variables will be sent through the interface when that plan

is activated.

6.3 Risks for Preliminary Implementations

6.4 There are some inherent risks to implementers of

the EDA interface specified in this document.

Significant risks include:

6.4.1 TCP/HTTP Limitations on Data Latency — Any

use of this standard in an application requiring

deterministic latency in the communication of data to

an off-tool application is at risk of failure due to late

delivery of data. Occasional delays in data delivery on

the order of a second or more can occur in TCP

communication due to the need for packet

retransmission. This is inherent in the TCP/IP protocol

used by HTTP, and cannot be addressed through

application design.

6.4.2 Data Collection Plan and Metadata Structure

and Formats are not Specified — The content and

transmission format of Data Collection plans and

Metadata for the proposed standard are left up to the

supplier. Standards are in process to define Metadata

and data collection plan content and data transmission

format in a standard way. The standard definitions may

be different than those defined by the supplier for the

proposed standard.

6.4.3 SOAP Protocol Usage — The SOAP usage

defined in this standard is targeted for point-to-point,

synchronous communication. This style of SOAP

communication may not be suitable for more

complicated communication models, and other

approaches may be required to achieve the objectives of

such applications.

6.4.4 XML/SOAP Limitations on Data Throughput —

While much has been done to optimize commercial

implementations of XML/SOAP messaging support,

end-to-end implementations on semiconductor

equipment have not been studied to quantify the

performance limitations of these technologies for data

collection, or to identify what hardware/software

configuration options are significant factors in

providing optimal throughput performance with these

technologies. If an implementation of this standard

requires meeting specific data throughput goals, it may

be necessary to evaluate the choice of networking

software drivers, application design, messaging

software toolkits used, hardware memory/cpu resources

or other elements when designing an implementation of

this specification. If the desired throughput goals

cannot be met by these design options, it may impact

the design of the message specification, the choice of

transport, or the mechanism for encoding the data

described in this specification.

NOTE 1: For information on factors contributing to SOAP

messaging performance, see http://www.extreme.indiana.edu/

~ mgovinda/research/papers/soap-hpdc2002.pdf

NOTE 2: For information on factors contributing to HTTP

performance, see http://www.w3.org/Protocols/HTTP/

Performance/

NOTE 3: For information purposes only, one example of

possible worst-case data throughput expectations for FDC

applications is available at http://www.sematech.org/public/

resources/ediag/background/eec032702.pdf.

7 Proposed EDA Interface Specification

7.1 Transport and Messaging

7.1.1 XML Schema Namespace — All XML element

information items defined in this specification belong to

the reserved SEMI namespace “urn:semi-

org:schema:eda_ps_v0.0”.

7.1.2 Separate Data Port — The proposed Equipment

Data Acquisition interface shall be a separate logical

port from the SECS/GEM control port on the tool.

7.1.3 Transport Mechanism — The transport

mechanism for the proposed EDA interface shall be

HTTP 1.1. The HTTP POST operation shall be used to

send messages to and from the equipment. There shall

be an HTTP connection from the equipment to the

client used for data only and another HTTP connection

from the client to the equipment, which will be used for

data management. These two HTTP connections

together make up a single EDA interface.

7.1.4 HTTP Performance Features — The client of the

equipment’s data port must operate in persistent

connection mode, as defined in HTTP 1.1. It is not

required that the data management connection of the

EDA port operate in persistent connection mode,

though that is the default mode for HTTP 1.1.

SEMI PR8-0703 © SEMI 2003 6

7.1.5 SOAP Binding — The SOAP binding specified in

this document shall be HTTP 1.1 in accordance with the

SOAP 1.1 W3C Note.

7.1.6 SOAP Message Style — Message encoding will

be XML document-style and not Remote Procedure

Call style. In document-style message exchange, XML

documents conforming to some application-defined

schema are exchanged via SOAP messages.

7.1.7 SOAP Action — The SOAP action HTTP header

field is used to facilitate dispatching individual

messages defined by this specification. The field will

contain a URI that indicates the specific operation in

the message. The URI will be a URN of the form:

“urn:semi-org:ws:eda_ps_v0.0:<OperationName>”.

Where OperationName corresponds to the name of the

root tag for each message.

7.1.8 SOAP Headers — This document specifies the

required use of a SOAP header element to describe the

source and destination of all messages between the

equipment and EDA clients (see Section 7.3.2 and to

correlate responses with requests (see Section 7.3.3).

The specification does not prohibit the use of additional

SOAP header elements, should an implementation of

this specification find them necessary.

7.1.9 SOAP encodingStyle — The SOAP

encodingStyle attribute is not used (i.e., not present on

any XML element information item) for the messages

defined in this specification.

7.1.10 SOAP Body — The SOAP body will contain an

XML fragment as defined in the Data Management and

XML Data Formats sections below.

7.2 SOAP Message Structure

7.2.1 Figure 3 shows the organization of each SOAP

message exchanged between the equipment and EDA

clients. This specification defines the value of the

SOAPAction HTTP header to use for each message

(see Sections 7.6.2.1 through 7.6.2.5), the SOAP

headers to be used for each message (Section 7.3), and

the elements that are included in the body of the SOAP

envelope for each message (see Sections 7.6.2.7 and

7.7).

HTTP Headers

SOAPAction

SOAP Envelope

SOAP Headers

<To />

<CorrelationId /> (optional)

</MessageHeader>

SOAP Body

<IsEdaEnabled />, or

<ActivatePlan />, or

<EdaData />, or

<GetDefinedPlanIdsResponse />,

Etc.

Figure 3

EDA Message Structure

7.3 SOAP Headers

7.3.1 This section describes a SOAP header element

(MessageHeader) that can be used to facilitate different

messaging implementations on both the equipment and

EDA client side of the interactions defined in this

specification. The SOAP header defined in this section

is provided to identify the sender and recipient of each

SOAP message included in this specification, and to

associate a specific message with other messages sent

by a given entity.

7.3.2 There are two elements specified for the purpose

of identifying the sender and intended recipient of a

SOAP message: a “From” element and a “To” element.

Both are required elements in the MessageHeader

element of each message exchanged in an

implementation of this specification. These elements

identify the sender or intended recipient of a given

SOAP message. These identifiers can be used to route

a message to an appropriate entity for processing, to

distinguish a specific message from other messages

received from other sources, or as a simple mechanism

for enforcing access controls.

7.3.3 This section also defines an optional element

(“CorrelationId”) within the MessageHeader element

that can be used to associate related messages (for

example, a request and its reply) among all messages

sent and received by a given entity. The entity in the

client role generates a value for the CorrelationId that

would be used by the server entity in its reply to

establish the correlation. Use of this element is

optional, and communicating entities are not required to

process it in order to exchange the messages in this

specification.

Table 2 MessageHeader XML Definition

Tag Name Description XML Datatype Behavior mustUnderstand

MessageHeader Container element for

From/To/CorrelationId.

complex Required 1

From Identifies the originator of

this message.

anyURI Required n/a

To Identifies the intended

recipient of this message.

anyURI Required n/a

CorrelationId Associates this message

with other messages in the

same message interaction.

string Optional (0 or 1) n/a

7.3.3.1 From Element — This element identifies the sender of a given SOAP message, whether the message is an

event, a request, or a response to a request. It is of XML type anyURI and can be any valid URL or URN. This

specification does not place any restriction on the format used to identify a sender, regardless of whether the sender

is the equipment or an EDA client. All messages originating from the same sender must provide the same value for

the From element so that the recipient may distinguish that sender from others.

7.3.3.1.1 Examples — Some examples of valid From elements are provided as follows:

• <From>urn:equipment-client:icm:utracking-01</From>

• <From>http://myfactory.com/furnace/KF011/EDA</From>

7.3.3.2 To Element — This element identifies the intended recipient of a given SOAP message. It is of XML type

anyURI and can be any valid URL or URN. This specification does not place any restriction on the form (URL or

URN) used to identify a recipient, regardless of whether the recipient is the equipment or an EDA client. All

messages intended for the same recipient must provide the same value for the To element so that the recipient may

distinguish that message from others intended for other recipients. If the message is a response to a request, the

value of the To element in the response must be equal to the value of the From element in the original request

message.

7.3.3.2.1 Examples — Some examples of valid To elements are provided as follows:

• <To>urn:equipment:robofurnace-inc:3JK9UI-02-99UI</To>

• <To>http://factory.icm.com/fdc/app-01</To>

7.3.3.3 CorrelationId Element — If used, the value of this element in the initial request message should be unique

for that client. Each request shall have a different CorrelationId value. For messages that are replies, the value shall

be equal to the value of the CorrelationId element provided in the original request message.

7.3.3.3.1 Examples — some examples of valid CorrelationId elements are provided as follows:

• <CorrelationId>5a389ad2-22dd-11d1-aa77-002035b29092</CorrelationId>

• <CorrelationId>4776</CorrelationId>

7.4 Equipment Configuration

7.4.1 Data Management Configuration — There shall be a persistent equipment configuration setting that controls

whether data management (see Section 7.6) is performed via SECS/GEM or via SOAP. The implementation and

behavior of this configuration setting is to be defined by the supplier, but shall not be implemented in such a way

that it is possible to perform data management via both SOAP and SECS/GEM concurrently. When the equipment

is configured to accept data management messages via SOAP, the equipment shall not accept these messages via

SECS/GEM. Likewise, when the equipment is configured to accept data management messages via SECS/GEM,

the equipment shall not accept these messages via SOAP. It must be possible for the factory to change this

configuration setting without requiring the involvement of the supplier.