semi合集-English.pdf - 第3279页

SEMI E128-0304 © SEMI 2003, 2004 13 natural use of asynchronous messaging that does not require the complexities of multi-threaded implementations and thread-safe program ming. R1-4 Request/Reply with Trailing Callbacks …

100%1 / 7923
SEMI E128-0304 © SEMI 2003, 2004 12
R1-2 Request/Reply (Asynchronous)
Client Server
Request
Reply
Request header
tells where to
send reply.
Interim
processing while
waiting for reply.
Figure R1-2
Asynchronous Request/Reply Interaction
R1-2.1 An asynchronous interaction can also support the semantics of a request/reply interaction. The request
message includes envelope header data that enables the service to perform the requested action and then construct a
“callback” reply message that is delivered to the request originator in a separate message delivery. In addition to
data identifying the request and reply endpoints, the message envelope header must include a request identity that
allows the requestor to correlate the reply message with the previously sent request message.
R1-3 Request/Reply with Interleaved Requests
Client Serve
r
Serve
r
Replies could
arrive in any
order.
Client never
blocks, wakes to
handle message
events.
Figure R1-3
Interleaved Requests Interaction
R1-3.1 An asynchronous messaging interaction may involve more than one request being processed at a time. In
this example, the Client requests actions from two separate Servers. The servers perform the actions and reply with
the results independently. The client receives the reply message in a non-deterministic order. In some cases, the
client may need to wait for both responses to proceed with its processing. This mechanism for parallel requests is a
SEMI E128-0304 © SEMI 2003, 2004 13
natural use of asynchronous messaging that does not require the complexities of multi-threaded implementations and
thread-safe programming.
R1-4 Request/Reply with Trailing Callbacks
Client Server
Request
Reply
Callback
Callback
Callback
Figure R1-4
Request with Trailing Callback Interaction
R1-4.1 A request may ask a Server to establish some activity that generates a series of callback messages. The
Client may just require a reply that acknowledges that the activity has been initiated with a trailing sequence of
independent messages that deliver the data of interest to the Client. This message pattern uses the RequestId from
the request message and the matching CorrelationId in the reply message to acknowledge the contract to deliver data
in the callback messages that follow. The use of a message body element for the MessageSequence enables the
Server to dynamically communicate the message sequence and establish intent to generate additional callback
messages.
SEMI E128-0304 © SEMI 2003, 2004 14
R1-5 Request/Reply with Leading Callbacks
Client Server
Request
Callback
Callback
Callback
Reply
Figure R1-5
Request with Leading Callback Interaction
R1-5.1 Another common message exchange pattern involves a request message, followed by a series of callback
messages providing status updates, with a final reply message that ends the interaction. This pattern is often used in
an application where there are events that might be of interest that occur during the performance of the requested
action. It is particularly useful if the Client may need to make decisions or take other actions based on the interim
callback messages that are provided in lead of the reply.