semi合集-English.pdf - 第3284页

SEMI E128-0304 © SEMI 2003, 2004 18 constrained to a single session context, and can be separat ed in time. There is no “blo cking” on pending repl ies. This model lends itself better to clients or servers th at deal wit…

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.

Received HTTP POST:

POST getCounter HTTP/1.1

Host: localhost:9000

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

Content-Length: 416

SOAPAction: getCounter

<From>localhost:9000</From>

<To>localhost:9001</To>

<MessageType>REPLY</MessageType>

<Action>getCounter</Action>

</MessageHeader>

</Header>

<Body>

</Body>

</Envelope>

Figure R2-3

Example HTTP Post Reply Message

R2-3 Java Message Service

R2-3.1 The Java Message Service example is based on the same example application, but with a JMS

implementation. This example shows how message-oriented middleware can be used to provide persistent and

guaranteed messaging, without changing application code. All transport-specific messaging is confined to the Java

classes that implement the example. Application code is only exposed to the XML messaging transport interface

and the XML Envelope specification.