semi合集-English.pdf - 第3282页

SEMI E128-0304 © SEMI 2003, 2004 16 RELATED INFORMATION 2 MESSAGE TRANSP ORT EXAMPLES NOTICE: This related i nformati on is not an official part of SEMI E128 and was derived f r om the wor k of the originating committee.…

100%1 / 7923
SEMI E128-0304 © SEMI 2003, 2004 15
R1-6 Request/Reply with Timeout
Client Server
Request
Server
takes too
long to
respond
Interim
processing
Set timer
Timer triggers
result handler
Figure R1-6
Request/Reply with Timeout Interaction
R1-6.1 A common messaging pattern that takes advantage is a request/reply that enables the Client to take alternate
action if a reply is not received within a predefined time interval. This enables fault tolerant design that ensures that
the client can recover from errors that prevent timely, or any, response from the server. The mechanism for the
triggering of the timeout can itself be based on a messaging interaction with the request setting a timer and the reply
reporting the timer expiration.
SEMI E128-0304 © SEMI 2003, 2004 16
RELATED INFORMATION 2
MESSAGE TRANSPORT EXAMPLES
NOTICE: This related information is not an official part of SEMI E128 and was derived from the work of the
originating committee. This related information was approved for publication by full letter ballot procedures.
R2-1 Transport Independence
R2-1.1 The aim of these examples is to keep implementation and transport mechanism specifics separated from the
use of the XML Messaging Specification. The example interface consists of five operations:
• start(myName) — starts the messaging send/receive endpoint,
• send(destName, envelope) — sends a message to another endpoint,
• stop()— terminates the messaging endpoint,
• onMessage(envelope) — callback provided by an application to process incoming messages, and
• receive() — waits for next message (needed when onMessage is not supported).
R2-1.2 This kind of interface abstracts the minimum functionality needed to send and receive messages. Any
potential message transport (HTTP, JMS, HSMS, RMI, etc.) could be encapsulated into methods similar to these to
keep the messaging implementation independent of the transport. An application could then be written using HTTP
today and then easily switched to JMS a year later. Also, new applications could be prototyped with lightweight
transports and deployed with robust MOM transports with no change to application code.
R2-1.3 This Related Information is based on a simple example (illustrated in Figure R2-1) of a typical interaction
between a client application sending requests to a server which provides the service and sends reply messages. The
purpose of this example is to illustrate the way the message header elements proposed in this specification are
realized in an asynchronous messaging implementation over HTTP.
SEMI E128-0304 © SEMI 2003, 2004 17
Clien
t
Serve
r
“getCounter" Request , cId = 1
“getCounter" Reply , cId = 1
“setCounter" Request, cId = 2
“setCounter" Reply, cId = 2
counter = 0
counter = 123
counter = 123
“getCounter" Request , cId = 3
“getCounter" Reply , cId = 3
counter = 123
“bogusAction" Request , cId = 4
“bogusAction" Reply , cId = 4
Fault Value = badrequest
Figure R2-1
Sample Interaction for Messaging Examples
R2-1.4 In order to show this example in an application context, it was implemented in Java for both HTTP and JMS
transports. The examples that follow were extracted from this sample application and the debug output of the
running example.
R2-2 SOAP/HTTP
R2-2.1 Since HTTP is inherently synchronous, a common implementation would support only synchronous
request/reply and would not use any of the MessageHeader elements that support asynchronous messaging. In the
synchronous case, only the To and Action elements would be present in the MessageHeader. The To element would
map to the URL of the target service and Action could also be URL encoded.
R2-2.2 To implement asynchronous messages over HTTP, both client and server endpoints must listen for messages
coming through the selected transport. Each message is interpreted based on both the transport properties and the
XML MessageHeader included in the SOAP header. Unlike more typical HTTP usage, the request and reply are not