English original reference: http://www.codeproject.com/cs/webservices/webservicecallback.asp?target=web|service
Because the time is tight, many local translations are not very suitable, welcome everyone to correct, thank you!
Use Web Service's Callbacks mechanism in .NET
- This article describes a web service-driven application model using a virtual web service agent (C #)
Introduction: Web Services When accessing the page using the 'Request / Response' method of Web Page, you can use a simple connectionable service.
Typically, these services use some local resources, such as application servers, databases, file servers, and more. In this example, Web Services look like an Internet container for local applications. This article describes connectable components that use web services in the application model to be used as a URL address. I will let you see how to call any web service in loosely coupled design mode and use the CallBacks mechanism. Based on these features, this distributed application model can be virtualized and can be referred to as application knowledge base. The metadata of the Application Knowledge Base is driven. In the details described below, you will learn the virtual Web service agent implementation method and the Callback mechanism that communicates between the Web Service.
Concept and design:
The client calls Web Service through the derived class HttpWebClientProtocol of the ASP.NET Web Service base class. This class can complete all the underlying works that map the Web Method into the SOAP message method. (SOAP is the default protocol). This proxy web serviced1.exe can be generated by this tool and can then be integrated into this project. Note that this proxy class can be independent for each web service. The client needs to fully understand its public interface for this Web Service before the project compilation. This approach is suitable for tight coupling applications. How do I handle this situation if the client doesn't know which web service will be called? Well, for this "logical" connection, we create a proxy class by using the previously mentioned Web Service Description Language Web ServicesDL. This logical connection concept is a loosely coupled.
The following picture shows the location where the web service is in the .NET application model.
What is "software bus" "pluggable", we have to understand it is implemented on the Internet. Note Web Service can run behind the firewall. If there is no firewall, you can use other .NET technology, such as: .NET Remoting, .NET Services, etc..
For software bus, Web Service is two-way - listening and sending messages. On the other hand, the application service or web client is passive, so they can only use the Web Service service. In addition, the application server uses few Web Service resources to schedule messages incorporated from the software bus.
This architecture model also applies to subsystem applications. At this time, Web Service plays a role of a gateway, which can map the web remote method to a local application service. Other advantages of the software bus are: Data exchanges and their abstraction definitions, which can be implemented by XML technology so that Web Service can exchange data in different platforms.
There are many rules using Web Service in your application very similar to components that run in the COM / MTS environment, mainly below:
Ø WebMethod is stateless, Web Service has the ability to save status when you call each other. Ø WebMethod execution, the client should use asynchronous calls, which will work together with other calls.
Ø WebMethod is the root of (transaction flow), if this WebMethod is defined as transaction mechanism, then it is the source of transactions. Note that in the current version of the .NET Framework, does not support transactions across the Internet. The transaction has more converted to a local transaction - refer to the concepts and patterns of the MSMQ transaction.
Ø Object reference cannot be used in parameters or return values, which means only the status of the object between the consumer and the Web Service. In fact, the sender serializes an object (it's a common state) is XML, and the recipient is again in the other party.
The architecture model of the above surrounding software bus allows for a growing commercial model to be constructed in a real distributed hierarchy application. This picture can only indicate the browser-based client, which can actually be an electronic device (such as the wireless Internet closure) that can access Internet bridges and gateways. Now let's take a look at it Detail of the web service mechanism.
Web Service Callback principle
The following pictures show an example of Web Service Callback:
Web service "a" uses WebMethod to process Callback from Web Service "B". Each Web Service has its own global state (Global State) to maintain the status of each other. The access to WebMethod is implemented by the virtual proxy class, and it is divided into two phases:
The client uses the beginInvoke / endinvoke design mode and uses synchronous or asynchronous mode to call the proxy class.
Agent class in synchronization mode calls WebMMETHOD
Web service "a" needs to pass two returned parameters to Web Service "B"; one is a Callback service and the other is its status. This mechanism is similar to the BeginInvoke / EndInvoke design pattern. The Callback Web Method signal has two parameters, which are SenderID and Eventargs, respectively. The return value is the BOOL type, a processing tag (continuing or abort). The call is based on the loose coupling design pattern of metadata (URL address of Web Service WSDL).
How does it work? The browser client sends a request to Web Service "a" to execute. This period of Web Service "A" returns the callback from Web Service "B" from Web Service "a". At this moment, the client can update the current page or enter a new request to abort the previous requirements.
The following code snippet shows how simple is the use of the WebServiceAccessor class implementation process.
[WebMethod]
Public String DosomeWorka (int COUNT, STRING Ticket)
{
// ...
// Call The Webservice B
WebServiceAccessor WSA = New WebServiceAccessor (TargetWsdlurl);
Object esobj = wsa.createInstance ("serviceb");
Object retval = wsa.invoke (esobj, "begindosomeworkb", count, mywsdlurl, state, null, null;
// ...
}
[WebMethod]
Public Bool CallbackServicea (String Sender, String Xmleventarg)
{
WebServiceEventarg EA = (WebServiceEventArg) XMLEventArg;
// ...
}