semi合集-English.pdf - 第3277页

SEMI E128-0304 © SEMI 2003, 2004 11 RELATED INFORMATION 1 USAGE SCENARIOS 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. Th is relat…

SEMI E128-0304 © SEMI 2003, 2004 10

6.6.7 Example Callback Message for a Fixed Number of Events — Figure 8 shows another callback message from a

server to a client. The CorrelationId “9” allows the client to correlate the callback with a prior request message.

The EventIndex element establishes this callback as the third of five callbacks. When the value of Position equals

the value of Total, then the client will know not to expect any further callback messages with this 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">

<To>EqHost</To>

<MessageType>CALLBACK</MessageType>

<Action>dataSubscribe</Action>

</EventIndex>

</MessageHeader>

</SOAP-ENV:Header>

<SOAP-ENV:Body>

<data>

</DATASET>

</DATASETS>

</data>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Figure 8

Callback Message (Fixed Number of Events) Example

7 Related Documents

None.

NOTICE: SEMI makes no warranties or representations as to the suitability of the standards set forth herein for any

particular application. The determination of the suitability of the standard is solely the responsibility of the user.

Users are cautioned to refer to manufacturer’s instructions, product labels, product data sheets, and other relevant

literature, respecting any materials or equipment mentioned herein. These standards are subject to change without

notice.

By publication of this standard, Semiconductor Equipment and Materials International (SEMI) takes no position

respecting the validity of any patent rights or copyrights asserted in connection with any items mentioned in this

standard. Users of this standard are expressly advised that determination of any such patent rights or copyrights, and

the risk of infringement of such rights are entirely their own responsibility.

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

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.

R1-2 Request/Reply (Asynchronous)

Client Server

Request

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

Serve

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