semi合集-English.pdf - 第3269页

SEMI E128-0304 © SEMI 2003, 2004 3 NOTICE: Unless ot herwise i ndicated, all docum ents cited shall be the latest published versions. 5 Terminology 5.1 Abbreviations an d Acronyms 5.1.1 SOAP — Sim ple Object Access Proto…

SEMI E128-0304 © SEMI 2003, 2004 2

will be used to represent the interfaces intended for

asynchronous message exchange patterns.

2.2 Out of Scope — The following topics are beyond

the scope of this specification. These topics may be

addressed in separate specifications, but are not

intended as future additions to this standard.

2.2.1 Message Security — The specification does not

provide mechanisms for authentication of the message

sender or receiver or for securing the content of

messages from unauthorized access.

2.2.2 Quality of Performance — The XML Messaging

Specification does not provide performance

requirements or conformance testing for the

performance characteristics of message transports.

There may be environments in which XML messaging

structures are not appropriate or effective for high

performance communications. The definition of the

environments where XML Messaging may or may not

be appropriate is beyond the scope of this document.

NOTICE: This standard does not purport to address

safety issues, if any, associated with its use. It is the

responsibility of the users of this standard to establish

appropriate safety and health practices and determine

the applicability of regulatory or other limitations prior

to use.

3 Limitations

3.1 Provisional Standard Deficiencies — This

document is Provisional due to areas where the

specification needs additions. When these missing

topics are addressed with subsequent revisions, this

standard will be upgraded to remove Provisional status.

The following items are cited as deficiencies in this

document:

3.1.1 SOAP 1.2 — This specification depends on the

W3C SOAP standard. The release of the full SOAP 1.2

W3C Recommendation is anticipated in early 2003.

Once it is formally adopted, this specification will need

to make adjustments for changes between SOAP 1.1

and SOAP 1.2.

3.1.2 Namespace for XML Messaging Schema — This

provisional specification will need to be aligned with a

future guideline for the specification of namespaces

belonging to SEMI Standards.

3.1.3 Structure for Publish/Subscribe Event Messages

— This provisional specification does not yet provide

mechanisms for defining messages for distribution via a

multicast publish/subscribe mechanism.

3.1.4 Structure for Attachments with Non-XML Data

— This provisional specification does not yet specify

the message structure for messages that have both a

SOAP envelope and a message attachment containing

non-XML data.

3.1.5 WSDL Requirements — The provisional

specification does not yet specify the form of WSDL

required for exposing services for access using

asynchronous messaging. Additional investigation into

WSDL and SOAP 1.2 Message Exchange Patterns is

required before completing the WSDL section of this

specification.

4 Referenced Standards

4.1 World Wide Web Consortium (W3C) Standards

Extensible Markup Language (XML) 1.0 (Second

Edition) — W3C Recommendation, 6 October 2000.

(See

http://www.w3.org/TR/2000/REC-xml-20001006.)

The latest version of Extensible Markup Lanuage

(XML) 1.0 is available at

http://www.w3.org/TR/REC-

xml.

Namespaces in XML — W3C Recommendation, 14

January 1999. (See

http://www.w3.org/TR/1999/REC-

xml-names-19990114/.) The latest version of

Namespaces in XML is available at

http://www.w3.org/TR/REC-xml-names.

XML Schema Part 1: Structures — W3C

Recommendation, 2 May 2001. (See

http://www.w3.org/TR/2001/REC-xmlschema-1-

20010502/.) The latest version of XML Schema Part 1:

Structures is available at

http://www.w3.org/TR/xmlschema-1/

XML Schema Part 2: Datatypes — W3C

Recommendation, 2 May 2001. (See

http://www.w3.org/TR/2001/REC-xmlschema-2-

20010502/.) The latest version of XML Schema Part 2:

Datatypes is available at

http://www.w3.org/TR/xmlschema-2/.

Simple Object Access Protocol 1.1 (SOAP) — W3C

Note, 8 May 2000. See

http://www.w3.org/TR/2000/NOTE-SOAP-20000508).

The latest version of Simple Object Access Protocol 1.1

is available at

http://www.w3.org/TR/SOAP.

Web Services Description Language 1.1 (WSDL) —

World Wide Web Consortium, 15 March 2002. This

version of the Web Services Description Language

Note is

http://www.w3.org/TR/2001/NOTE-wsdl-

20010315. The latest version of Web Services

Description Language is available at

http://www.w3.org/TR/wsdl.

1 All standards available from the website: www.w3.org. World

Wide Web Consortium, Massachusetts Institute of Technology (MIT)

Laboratory for Computer Science, 200 Technology Square,

Cambridge, MA 02139, USA. Telephone: 1.617.253.2613 Fax:

1.617.258.5999

SEMI E128-0304 © SEMI 2003, 2004 3

NOTICE: Unless otherwise indicated, all documents

cited shall be the latest published versions.

5 Terminology

5.1 Abbreviations and Acronyms

5.1.1 SOAP — Simple Object Access Protocol

5.1.2 WSDL — Web Services Definition Language

5.1.3 XML — Extensible Markup Language

5.2 Definitions

5.2.1 asynchronous messaging — a style of

communication based on the exchange of atomic

messages separated in time and implemented with one-

way message deliveries.

5.2.2 callback message — a message that

communicates supplemental information resulting from

performance of an action initiated by a related

request/reply conversation.

5.2.3 message document — an XML document that

contains the message envelope and encapsulated

message header and message content.

5.2.4 message envelope — the encapsulating XML

structures that define an overall framework for

expressing what is in a message; who should deal with

it, and whether it is optional or mandatory.

5.2.5 reply message — a message that contains data

resulting from the completion of an action initiated by a

related request message.

5.2.6 request message — a message that contains

necessary information to allow a server to perform a

requested action on behalf of the requester.

6 Requirements

6.1 Simple Object Access Protocol (SOAP) Envelope

— Messages shall be enclosed in the Envelope element

as specified in the SOAP 1.1 document. The SOAP

Envelope shall include a Header element and a Body

element. Within the Header element, message

documents shall include an element named

MessageHeader that contains data required for message

preparation and transport as specified below.

6.2 SEMI XML Messaging Namespace — All XML

items defined in this specification belong to the

reserved SEMI namespace “urn:semi-

org:schema:xmlmsg:0:0”. The following XML

Namespace declaration shall be used to specify the

namespace.

<xsd:schema xmlns="urn:semi-

org:schema:xmlmsg:0:0"

elementFormDefault="qualified" >

6.3 Use of SOAP Messages for Synchronous

Request/Reply Interactions — The XML Messaging

Specification does not preclude the use of SOAP for

synchronous interactions. The SOAP Header

Extensions specified in this document are not required

for a synchronous exchange, but may be useful even in

those cases. A standard adopting a synchronous use of

SOAP shall clearly indicate whether the header

extensions are required for conformant

implementations.

6.4 SOAP Header Entry for Messaging — The SOAP

message shall have an entry contained in the

SOAP-ENV:Header element named MessageHeader

that contains elements as defined in this section. The

MessageHeader element shall be defined with a

mustUnderstand = “1” attribute that requires all

conformant implementations to process the header

element or return a “MustUnderstand” fault to the

message sender.

6.4.1 From — The From element shall identify the

application that sent this message. The format of the

value in the From element shall be a valid URI. The

domain of the value in the From element may vary by

transport binding.

6.4.2 To — The To element shall identify the

application that is the intended recipient of this

message. The format of the value in the To element

shall be a valid URI. The domain of the value in the To

element may vary by transport binding.

6.4.3 MessageType — The MessageType element

shall identify the role of the message in a conversation.

A message shall be either a request, reply or callback

message.

6.4.4 Request Message — A request message shall

originate from an endpoint in the client role and shall

establish a new RequestId. The RequestId shall be

unique within the domain of all such Ids generated by

the originating client. The request message body

contains the information needed by the server to enable

it to perform a requested action on behalf of the client.

6.4.4.1 Reply Message — A reply message shall

originate from an endpoint in the server role and shall

echo the RequestId received from a client in a prior

request message as a CorrelationId. The reply message

body may contain information that conveys the

completion of an action initiated by a related request

message. It may instead include a body entry for a

Fault that communicates the reason for a failure. In

other cases the Fault may provide information such as

SEMI E128-0304 © SEMI 2003, 2004 4

warnings that supplement the normal content of the

body.

6.4.4.2 Callback Message — A callback message shall

originate from an endpoint in the server role and shall

echo the RequestId received from a client in a prior

request message. A callback message body contains

unspecified information that relates to the requested

action initiated by a related request message. A

callback message may precede the reply message (a

leading callback message), or it may follow the reply

message (a trailing callback message). The callback

message shall also contain an element for the

EventIndex if the server will send more than one

callback message. The body of a callback message may

also contain SOAP Faults if there is a processing error

that needs to be conveyed to the client.

6.4.5 RequestId — The RequestId element shall be

used in a request message to identify it as the first of a

series of messages that belong to a single interaction.

The value of RequestId shall be generated by a client

with the initial request message and then shall be

echoed back as the CorrelationId in subsequent

callback messages or reply messages from the

responding server. The XML Schema shall specify a

choice between RequestId and CorrelationId.

RequestId shall be the choice when MessageType is

“Request”.

6.4.6 CorrelationId — The CorrelationId element

shall be used in each reply or callback message to

identify it as part of an interaction that was initiated by

a prior request message. The value of CorrelationId

shall be identical to the RequestId from the initial

request message. The same CorrelationId value shall

be echoed back in all callback messages or reply

messages sent from the server in response to the client’s

initial request message. The XML Schema shall

specify a choice between RequestId and CorrelationId.

CorrelationId shall be chosen when MessageType is

“Reply” or “Callback”.

6.4.7 Action — The Action element shall be a string

that serves to identify the unit of functionality invoked

by the request message. An Action value shall be

unique to the recipient of the message.

6.4.8 ReplyExpected — The ReplyExpected element

is optional. When present, the ReplyExpected element

shall indicate whether the client expects to receive a

reply message by a “true” value. When present with a

value of “false”, the ReplyExpected element shall

indicate that the client does not expect to receive a reply

message. If not present, the server receiving the request

shall assume that a reply is expected (equivalent to a

“true” value). A service shall be prepared to return a

reply for every request, and a client shall be prepared to

receive replies even if this element is set to “false”.

ReplyExpected is intended only for optimizing

conversations where the client intends to ignore reply

messages.

6.4.9 MessageId — The MessageId element shall be

optional in the MessageHeader to define a string value

to uniquely identify the message. MessageId need not

be included in the MessageHeader if there is no value

established for uniquely identifying each message by

the selected message transport. If present, MessageId

shall be globally unique.

6.4.10 EventIndex — The EventIndex element shall be

optional in the MessageHeader of a callback message.

EventIndex shall not be included in request or reply

messages. Within the MessageHeader of a callback

message, EventIndex is optional only if there is just one

callback message in an interaction, but required if there

are a series of callbacks. EventIndex is used to identify

this message’s position in relation to multiple callback

messages resulting from the original request.

6.4.10.1 EventIndex Sub-elements — EventIndex shall

contain sub-elements for Position, and either Total or

Finished as specified in the following paragraphs.

Either Total or Finished shall be present, but not both.

6.4.10.2 Position — The Position element shall

indicate this message’s position in a stream of callback

messages. Position shall be greater than or equal to 1.

Position shall be less than or equal to Total, when Total

is present.

6.4.10.3 Total — The Total element shall indicate the

final count of callback messages to be delivered in this

interaction (that is, all messages sharing a common

RequestId/CorrelationId). Total shall have the same

value in each callback message in the sequence.

6.4.10.4 Finished — The Finished element shall

indicate whether this is the last in a sequence of

callback messages. Finished shall be present in callback

messages for interactions in which the total number of

callback messages cannot be known in advance. A

value of “false” shall indicate that additional callback

messages will be sent. A value of “true” shall indicate

that no further callback messages will be sent.

6.4.10.5 Default Interpretation if EventIndex is not

Present — If EventIndex is not present, the client

receiving the callback message shall interpret it as

equivalent to a EventIndex element with Position = 1

and Total = 1, indicating a single callback message

from server to client.