WSe 3.0 document translation: WSE Architecture

Author: jillzhang
Statement: for the first time, I tried to translate documents. The English language is very good.

As the most important part, WSE is an engine that provides extensions for soap messages. It can write the SOAP header information in the sent message and read the SOAP header information in the received message, it also needs to transmit soap bodies-for example, using WS-Security specifications to encrypt and decrypt received data. This function is encapsulated into two filters: one for sending data and the other for receiving data. All messages that exit the process-client request messages and server-side response messages are filtered by sending. All messages that enter the process-server receives the request and client receives the response are filtered by receiving. The following graph shows the structure of WSE:

 

Like the basic structure of ASP. net xml Web Service, the WSE filter is integrated in the SOAP message of WSE.

Integration with ASP. net xml Web Service proxy (sender)

The WSE sending and receiving filters are exposed to the ASP. net xml Web Service client through a class named webservicesclientprotocol. This new proxy base class extends the original Proxy Base class:System. Web. Services. soaphttpclientprotocol.The new proxy base class filters exchanged messages whenever the client sends messages. To use WSE, you must set the original Proxy Base class to webservicesclientprotocol, to simplify the procedure, you can use the tool in WSE

Webservicesclientprotocol implements two standard system. Net Communication classes: webrequest and webresponse. At a higher level, webrequest is responsible for sending data, and webresponse is used to receive data.

The webrequest instance puts the stream data containing soap messages into an instance named soapenvelope. This class is an extension of the standard. Net dom api: system. xml. xmldocument.

When the filter is sent, the filter has the opportunity to make any modifications to each request data. Generally, a message header is added and sometimes changed, for example, the message body data is encrypted.

The action of the filter depends on the declarative policies of the SOAP message. These policies are composed of ordered declarations. These lifecycles define a set of accepted or sent filters, each send filter policy declaration is passed to soapenvelope in the Policy Specification.

The following diagram shows how a SOAP message uses a series of filters.

 

The webresponse operation is opposite to webrequest. It obtains the data stream from the soap information and encapsulates it in the object instance named soapenvelope, and then passes it to the receiving filter. Each receiving filter has the opportunity to make any changes to the response message. the receiving filter verifies the message header and the sending filter performs reverse operations (such as decryption) on the soap body. Like webrequest, webresponse is also defined by declarative policies.

The following diagram shows how the response data is filtered by a set of filters.

 

Webservicesclientprotocol uses webrequest and webresonse, so you do not have to operate them directly. However, you still need a way to manipulate the Protocol attributes for sending and receiving data. Therefore, webservicesclientprotocol exposes two attributes: requestsoapcontext and responsesoapcontext. These objects reflect the next request message and the last received message.

Integration with ASP. net xml Web Service (receiving end)

Messages sent and received are exposed to ASP. net xml Web Service through a factory-type wseprotocolfactory of the server-side SOAP protocol. The new protocol factory class aims to give the opportunity to change the exchanged SOAP message when the network service method is not executed.

Wseprotocolfactory copies the received message to the data stream. Before the data is serialized as a parameter, the receiving filter can process it. These extensions also create data streams for the target method and serialize the output parameters. After the serialization step is complete, the parameters are passed to the target method through the WSE filter.

To enable Web Service to use wseprotocolfactory, you must configure it in Web. config. In particular, add the <soapserverprotocolfactory> node to the virtual directory where the Web Service is deployed.

Use TCP to send and receive soap messages

WSe allows TCP to send and receive soap messages. In this way, the web server can be used to write flexible and lightweight network services. WSe supports the one-way message model and a request/response pair model. The one-way model is implemented through soapsender and soapsener. Both one-way and request/response can be implemented through soapclient/soapserver.

Author: jillzhang
Statement: for the first time, I tried to translate documents. The English language is very good.