semi合集-English.pdf - 第3278页

SEMI E128-0304 © SEMI 2003, 2004 12 R1-2 Request/Reply (As ynchronous) Client Serv er Request Reply Request header tells w here to send reply . Interim processing while waiting for reply. Figure R1-2 Asynchronous Request…

100%1 / 7923
SEMI E128-0304 © SEMI 2003, 2004 11
RELATED INFORMATION 1
USAGE SCENARIOS
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.
R1-1 Request/Reply (Synchronous)
Client Server
Request
Reply
Blocking
Request session
waits for reply,
no routing info
needed in
Figure R1-1
Synchronous Request/Reply Interaction
R1-1.1 The synchronous form of request reply shows the client blocking after sending a request message to wait for
the reply message. The transport used in a synchronous interaction typically manages the correlation of the request
with the reply by completing the interaction in a single step. Synchronous interactions have the advantage of
simplicity.
R1-1.2 Synchronous interactions often also come with limitations. The client may not perform other activities
while waiting for the reply. If the requested action takes a long time, this can limit the client’s ability to respond to
other events. Another limitation is the risk of having a failure occur in the server that is not reported to the client. In
general, synchronous interactions may prove more fragile than asynchronous messaging in distributed systems.
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.