semi合集-English.pdf - 第3268页
SEMI E128-0304 © SEMI 2003, 2004 2 will be used to represent the interfaces intended for asynchronous message exchan ge patterns. 2.2 Out of Scope — The foll owing topics a re beyond the scope of this specification. Thes…
SEMI E128-0304 © SEMI 2003, 2004 1
SEMI E128-0304
PROVISIONAL SPECIFICATION FOR XML MESSAGE STRUCTURES
This provisional specification was technically approved by the Global Information & Control Committee and
is the direct responsibility of the North American Information & Control Committee. Current edition
approved by the North American Regional Standards Committee on October 16, 2003 and December 4, 2003.
Initially available at www.semi.org February 2004; to be published March 2004. Originally published July
2003.
1 Purpose
1.1 This standard specifies XML structures required to
encode message header or “envelope” information for
asynchronous messages. It applies to applications
conforming to other SEMI standards only if they use
asynchronous XML messaging for communication.
XML is used in software applications to encode
information with tags that provide structure and data
type information specified in XML Schemas. XML is
also used to structure information needed to route and
deliver messages between applications. A standard for
message headers is required to avoid development and
use of multiple incompatible protocols based on XML.
This specification will be referred to as “The XML
Messaging Specification.”
1.2 The XML Messaging Specification provides
definitions of message headers needed for messages
exchanged in an asynchronous fashion. Asynchronous
messages are delivered independently without
dependence on transport technology to correlate related
messages. The rationale for choosing an asynchronous
message delivery mechanism is based on the
characteristics of the interaction between two software
systems. Some of these reasons are that:
• Support for long-running Request/Reply
interactions may not be practical in a synchronous
session-oriented communication.
• Some messaging interactions require additional
callback messages reporting on server activity
which supplement the reply message.
• Clients may wish to interleave requests and replies
to manage parallel or overlapping activities in
multiple concurrent messaging conversations.
1.3 The base technology supporting asynchronous
messaging may also support synchronous interactions
that rely on transport sessions for identification and
correlation of related messages. The XML Messaging
Specification does not prevent these synchronous
messaging dialogs since the specified header elements
are not required in these cases. However, there may be
benefits of using the message header elements specified
here even in synchronous interactions. The message
header elements provide self describing information
about messages that may be useful for debugging or
tracking message traffic. Their use may also enable
future migration to different message transports.
1.4 The XML Messaging Specification uses
established, openly referenceable industry standards for
XML messaging where possible. It only specifies
extensions to existing industry standards when needed
to meet the immediate requirements for messaging in a
SEMI Standard application context. The intent of this
standard is not to replicate existing standards or offer
competing specifications, but to align with and cite the
usage of existing standards.
2 Scope
2.1 In Scope — The XML Messaging Specification
will include within its scope the following:
2.1.1 Use of the W3C Simple Object Access Protocol
(SOAP) — SOAP is used as a basic message foundation
for SEMI messaging applications.
2.1.2 Definition of SOAP Extensions — This
specification defines SOAP extensions for header and
body elements needed to support asynchronous
messaging interactions.
2.1.3 Structures for Request/Reply Point-to-Point
Message Dialogs — This specification will address the
message header data needed to support request/reply
interactions with a request message and corresponding
reply message using asynchronous, one-way messages.
2.1.4 Structures for Asynchronous Point-to-Point
Callback Messages — This specification will address
the message header data needed to enable atomic,
asynchronous callback messages that complement a
request/reply dialog between two endpoints.
2.1.5 Structures for Asynchronous Multicast Event
Messages — This specification will address the
message header data needed to enable atomic,
asynchronous event messages distributed via a
publication multicast to multiple subscribers.
2.1.6 Use of W3C Web Services Definition Language
(WSDL) — WSDL is a message metadata specification
language for describing signatures of web service
interfaces. This specification will define how WSDL
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
1
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