semi合集-English.pdf - 第3270页

SEMI E128-0304 © SEMI 2003, 2004 4 warnings that supplement the normal content of the body . 6.4.4.2 Callback Mess age — A callback message shall originate from an en dpoint in the server role and shall echo the RequestI…

100%1 / 7923
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.
SEMI E128-0304 © SEMI 2003, 2004 5
6.4.11 MessageHeader XML Schema — The XML schema in Figure 1 defines the MessageHeader element that is
required by this specification.
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="urn:semi-org:schema:xmlmsg:0:0"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<xsd:element name="MessageHeader">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="From" type="xsd:anyURI"/>
<xsd:element name="To" type="xsd:anyURI"/>
<xsd:element name="MessageType">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="REQUEST"/>
<xsd:enumeration value="REPLY"/>
<xsd:enumeration value="CALLBACK"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:choice>
<xsd:element name="RequestId" type="xsd:string"/>
<xsd:element name="CorrelationId" type="xsd:string"/>
</xsd:choice>
<xsd:element name="Action" type="xsd:string"/>
<xsd:element name="ReplyExpected" type="xsd:boolean" minOccurs="0"/>
<xsd:element name="MessageId" type="xsd:string" minOccurs="0"/>
<xsd:element name="EventIndex" minOccurs="0">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Position" type="xsd:nonNegativeInteger"/>
<xsd:choice>
<xsd:element name="Total" type="xsd:nonNegativeInteger"/>
<xsd:element name="Finished" type="xsd:boolean"/>
</xsd:choice>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
Figure 1
Message Header XML Schema
6.5 SOAP Body Extensions — Any exceptions that occur shall be communicated with the use of SOAP Faults.
6.5.1 SOAP Faults — A SOAP Fault element shall be inserted into the SOAP body element as a body entry to
relay error status from the server back to the client. A body entry is a top level element within the Body element of
the SOAP envelope. SOAP Fault subelements are specified in SOAP 1.1 Section 4.4. Their usage is specified here.
6.5.1.1 fault — The fault element shall appear in the body of the SOAP envelope as a body entry whenever there is
an abnormal outcome in the server’s processing of a request message.
6.5.1.2 faultcode — The faultcode element shall be present in a SOAP fault element. The values specified in the
SOAP specification shall be used to indicate the nature of the error that occurred.
• “Client” indicates that the request message was not correct and could not be processed by the server.
• “Server” indicates that the request message was valid, but the server could not complete the requested action.