web| background because of the limited execution status of the Web service, we cannot directly let the Web service request as a soapreceiver, but through the following Web.config definition to develop this virtual directory's. ASHX endpoint, thereby passing Ws_ Addressing and ws_messaging mechanisms to complete the subscription/publishing mechanism between the background listening service.
<configuration>
<configSections>
<section name= "Microsoft.Web.Services"
Type= "Microsoft.Web.Services.Configuration.WebServicesConfiguration,
Microsoft.Web.Services, version=2.0.0.0, Culture=neutral,
Publickeytoken=31bf3856ad364e35 "/>
</configSections>
Principle Introduction:
In addition to the intra-process and TCP communication mechanisms, you can integrate SoapReceivers with the HTTP pipeline in asp.net. If you look at the definition of soapreceiver, you'll notice that it implements IHttpHandler:
Public abstract class Soapreceiver:soapport, IHttpHandler
{
。。。
}
Because of this, any soapreceiver or Sendservice class can now be configured as an HTTP handler in asp.net. By adding a new mapping in the httphandlers section of the Web.config file, the user can configure the HTTP handler. The web.config item will map the Verb/path combination to the SoapReceiver type:
<system.web>
<!--in order for our WebService to receive a SOAP message from the background listening service
We let webservice inherit from SoapReceiver and implement void Receive (SoapEnvelope envelope),
This DLL passes to the
New Uri ("http://" + System.Net.Dns.GetHostName () + "/myservice/getreceiver.ashx")
Sends a SOAP message, then the SoapReceiver receive callback function is invoked
-->
<add type= "Mywebservice.myinterface" path= "getreceiver.ashx" verb= "*"/>
Putting this set of code in place will call MyService for each message that enters this virtual directory and points to getreceiver.ashx. Now we don't have to worry about configuring Soapreceiver/soapservice by calling Soapreceiver.add because ASP.net essentially replaces you with this task.
If you update the client to send the message to the HTTP endpoint (HTTP://LOCALHOST/MYSERVICE/GETRECEIVER.ASHX), it will work the same way as using TCP, but it is now communicating over HTTP.
Web service-Background Listening service subscription relationship
Because the web The service runs as a asp.net user, and the Soapreceiver.add method requires higher execution permissions, so we use the HTTP endpoint, plus a few static hash tables, to complete the asynchronous interaction with the background listening service and the asynchronous interaction with the client caller.
Here's a concrete explanation:
First, the caller requests the Web serviced BeginXxx method, which asynchronously invokes the Processxxx method, which is responsible for assembling a soapenvelope and the URI
Soap.tcp://hostname:port/yourreceivername
The target endpoint, send this soapenvelope with Soapsender.send. Used to notify subscription relationships on the one hand, and pass parameters as well as pre generated GUIDs on the other. The processing right is then returned to the caller.
This includes the 1,2,3 three steps in the diagram:
Second, the listening service that is listening receives the message and processes it:
Add this subscriber's various information to the static hash table;
Perform various tasks asynchronously using I/O completion ports;
Notifies subscribers of a result set or error message through a Web Service HTTP endpoint.
This includes the 4,5,6 three steps in the diagram:
Finally, when the Subscriber Web service receives a notification, the client caller's callback function is notified to retrieve the result set, which returns the result set or the cause of the error to the client.
Written by: Zheng @ultrapower
