semi合集-English.pdf - 第3283页

SEMI E128-0304 © SEMI 2003, 2004 17 Clien t Serve r “getCounter" Request , c Id = 1 “getCounter" Repl y , cId = 1 “setCounter" R equest, cId = 2 “setCounter" Repl y, cI d = 2 counter = 0 counter = 123…

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

Serve

“getCounter" Request , cId = 1

“getCounter" Reply , cId = 1

“setCounter" Request, cId = 2

“setCounter" Reply, cId = 2

counter = 0

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

SEMI E128-0304 © SEMI 2003, 2004 18

constrained to a single session context, and can be separated in time. There is no “blocking” on pending replies.

This model lends itself better to clients or servers that deal with many messaging partners at a time, while still

needing to act on common data.

R2-2.3 In the HTTP/SOAP transport example, each of the messages in the sample scenario will be sent with an

HTTP Post operation. Every message will include an XML document containing a SOAP envelope and the

MessageHeader specified in this standard. The message body will contain the application specific elements that

communicate the content of each message.

R2-2.4 The elements of the MessageHeader contain data that is used to construct the appropriate HTTP message

and to populate the properties of the SOAP message. Specifically, the destination URL for each message appears in

the To attribute of the MessageHeader. The From attribute contains the URL of the sender of each message. The

SOAPAction HTTP header replicates the Action element in the transport specific header attribute.

R2-2.5 This example (and the ones that follow) include both the HTTP properties and the XML message from the

client perspective. The request message shown in Figure R2-2 illustrates the HTTP transport form of the message.

Sending HTTP POST:

POST getCounter HTTP/1.1

Host: localhost:9001

Content-Type: application/soap+xml; charset="utf-8"

Content-Length: 369

SOAPAction: getCounter

<From>localhost:9001</From>

<To>localhost:9000</To>

<MessageType>REQUEST</MessageType>

<Action>getCounter</Action>

</MessageHeader>

</Header>

</Envelope>

Figure R2-2

Example HTTP Post Request Message

R2-2.6 The reply message in Figure R2-3 follows the same pattern, with the TO header element reflected in the

HTTP Post and the SOAPAction mapping to the MessageHeader Action element. In this example, the same Action

value is echoed back with the reply message.