semi合集-English.pdf - 第3281页

SEMI E128-0304 © SEMI 2003, 2004 15 R1-6 Request/Reply w ith Timeout Client Serv er Request Server takes too long to respond Interim processing Set timer Timer triggers result handler Figure R1-6 Request/Reply with Timeo…

SEMI E128-0304 © SEMI 2003, 2004 14

R1-5 Request/Reply with Leading Callbacks

Client Server

Request

Callback

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.

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.