semi合集-English.pdf - 第3271页

SEMI E128-0304 © SEMI 2003, 2004 5 6.4.11 MessageHea d er XML Sche ma — The XML schema in Figure 1 define s the Messa geHeader element that is required by this specification. <?xml version="1.0" encoding=&qu…

100%1 / 7923
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.
SEMI E128-0304 © SEMI 2003, 2004 6
6.5.1.3 faultstring — The faultstring element shall be present to describe the cause of the fault in human
understandable text.
6.5.1.4 faultactor — The use of the faultactor element is optional.
6.5.1.5 detail — The detail element is optional. It may be used to describe the cause of a fault that resulted from
processing the body of the request message.
6.6 XML Message Examples — The examples of XML messages presented in this section are intended to help the
reader understand the structure of messages that conform to this specification.
6.6.1 Example SOAP Envelope — The SOAP envelope illustrated in Figure 2 contains the required Header and
Body elements. It also includes the MessageHeader element specified in this standard. The contents of these
elements are intentionally left empty in this example.
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-
ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header>
<MessageHeader>
</MessageHeader>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<PayloadData>
</PayloadData>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Figure 2
SOAP Envelope
6.6.2 Example Request Message — The message example shown in Figure 3 illustrates the completed
MessageHeader for a message from a client to a server to request a service. In this example, the SOAP Body
contains an element that identifies the data that is being requested with the Action “dataRequest.” The RequestId
assigned by the client is “7.” The client will expect a reply message that contains “7” in the CorrelationId.
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-
ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header>
<MessageHeader xmlns="urn:semi-org:schema:xmlmsg:0:0"
elementFormDefault="qualified">
<From>EqHost</From>
<To>EQ99</To>
<MessageType>REQUEST</MessageType>
<RequestId>7</RequestId>
<Action>dataRequest</Action>
<ReplyExpected>true</ReplyExpected>
</MessageHeader>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<data>
<DATAID type="ASC">420</DATAID>
</data>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Figure 3
Request Message Example