The purpose of writing this article: Recently, there are many articles on the 9CBS in the 9CBS for Web Service For Web Service, and Microsoft Soap Toolkit 2.0 is relatively small. Everyone discussed, basically stayed in a simple Web Service level in developing with Visual Studio .NET. And I think it seems that it is still not realistic, and the vast VC / VB programmers should develop SOAP applications. It seems that Microsoft SOAP TOOLLLKIT needs to be used. Therefore, the author hopes that it can be discussed in this article, and please do not enlighten me.
Microsoft SOAP Toolkit 2.0 Introduction
Although there are many kinds of implementation of SOAP, I think that the implementation of Microsoft is the best for VC / VB programmers. I will open the bottom library of WebServices in .NET (because I am not familiar with L), we are now discussing Microsoft Soap Toolkit 2.0.
Microsoft SOAP Toolkit 2.0 provides a complete set of COM objects to process all data related to SOAP, allowing you to use it without knowing SOAP and XML (of course, it is best to understand), you can use it easy and convenient to use it. Any programming language to write SOAP applications. What you see is a COM object (in line with Microsoft style, in line with the general programmer's program habits).
I. Features:
1. Provides the client's components that allow you to specify WSDL and easily call the corresponding Web Service.
2. Provides the server's components that allow you to specify WSDL, WSML, and COM objects to automatically generate Web Service.
3. It also provides the underlying processing component that allows you to manipulate the specific creation, processing, and transfer of the SOAP message.
Two. Several concepts:
WSDL (Web Services Description Language): Used to describe the XML format of the service provided by the server. In the WSDL file, the service provided by the server, the supplied call method, as well as the format you have to follow, such as the format of the parameter and the return value, and so on. WSDL is very similar to the IDL (Interface Description Language) in COM, which is a contract between servers and clients, and both sides must implement functionality.
WSML (Web Services Meta Language): The method used to describe the method provided in WSDL and the Map between the COM objects that implements the method. This file is unique to the implementation of Microsoft, not part of the SOAP standard. In general, the file exists only at the server.
SOAP message: Method call request and result return value in the client and server is placed in these messages, which is data in XML format.
Third. Web service call process:
Client: obtain the server's service description file WSDL, resolve the contents of the file, understand the service information of the server, and call mode. Generate an appropriate SOAP request message (specified method, parameters that have been called), sent to the server. Waiting for the SOAP response message returned by the server, resolve the return value.
Service: Generate a service description file for clients. Receive the SOAP request message sent by the client, resolve the method calls and parameter formats. According to the description of WSDL and WSML, call the corresponding COM object to complete the specified function, and put the return value into the SOAP response message to return to the user.
Four. Two modes of programming
High-level interface
With a high-level interface, you don't need to know any information for SOAP and XML, you can generate and use a WebService. SOAP Toolkit 2.0 completes these features by providing two COM objects - SoapClient and SOAPSERVER. On the client, you only need to generate a SOAPCLIENT instance and use WSDL as a parameter to call the MSSOAPINIT method. The SOAPCLIENT object will automatically parse the WSDL file and generate all web services methods and parameter information internally. After that, you can call all the methods in the same way as in calling the IDispatch interface. In VB or scripting languages, you can even directly add directly to the SOAPCLIENT object name. Method (parameter ...) is called.
In the server, there are two processing modes. One is to generate an ASP file; the other is to use the ISAPI extension, allowing the DLL provided by the SOAP Toolkit to process the request for WSDL.
In the first mode, you need to create a SOAPSERVER object in the ASP file and use WSDL and WSML as a parameter to call the init method, and SOAPServer will automatically establish a related mapping relationship inside. Then, use the ASP Request and Response objects as the parameter to call the SOAPINVOKE method. SOAPServer automatically obtains the user's SOAP request message from the request, and resolves, call the corresponding COM completion function, and package the return value into the SOAP response message, return to the Response object.
In the second mode, the ISAPI extension provided by SOAP Toolkit automatically completes all of the above ASP mode.
The comparison of the two modes is that the first is more flexible, but the speed is relatively slow. The second although flexibility is not, the performance is very high. So, use ISAPI mode if you don't have special.
Low-level interface
To use a low-level interface, you have to know about SOAP and XML. You can control the process of SOAP, especially when you want to do special processing.
At the client, first create an HTTPConnector object, responsible for HTTP connections. Set some head information of the Connector, such as EndPoinURL and SOAPAAPAAPAction. If the network connection needs to use the proxy server, you have to set the relevant information here. Then create a SOAPSERIALIZER object to generate a SOAP message. Follow the WSDL to serialize all parameters, get a complete SOAP request message. The SOAP message is sent as a PayLoad to the server via HTTPConnector. Finally, generate a SOAPReader object, responsible for reading the SOAP message returned by the server, and obtains the return value therein.
At the server, you first get the input and output of the HTTP connection through the Request and Response objects in the ASP. Then create a SOAPReader object, read the SOAP request message in the Request object, resolve the methods to be called and the parameters of the call, perform the actual call, and obtain the results. Finally, a SOAPSERIALIZER object is generated, according to the description of WSDL, serialization execution results, generate a SOAP response message, and return to the client via the Response object.
V. Doubt and answer
Why do you have WSML?
A: Because the SOAP itself is just an object access, it is not specified as in the implementation. In general, using SOAP is open to the standard manner in a standard manner, allowing the outside to access. On the Microsoft's platform, for the interoperability of the module, the implementation of the function is generally provided in a COM manner. How to map the methods described in WSDL to COM interface, this is what WSML is going. Now you can see, use WSML, you don't need to do too much work, you can make existing applications quickly into a Web Service app. At the server, you fully retain Microsoft's COM / COM application mode. (Of course, WSML is not necessary, if you don't need to use COM's method map. If you don't use the SOAP Toolkit's high-level interface, use the underlying interface. There is no need.) How to deal with complex data types?
A: You can implement a customized type mapping CUSTOM TYPE MAPPER and specify in WSML. In this way, the SOAP Toolkit is in the process, calling this Mapper to process the message in the SOAP message. For example, to return a complex data, on the server, Toolkit should know how to sequence a complex data type as an XML node. And in the client, Toolkit knows how to re-represent the XML node as a complex data structure.
It should be noted that this mapping object is not required, just for use in use. That is, as long as the two sides strictly follow the specification described in WSDL, they will be able to achieve successful calls. Regardless of how your client and server maps this complex data type, it is a C structure, it is a COM object, or a Java class is also unrelated.
Six. Examples of SOAP Toolkit
The example of Toolkit comes has been very comprehensive and explains the various call methods that use this Toolkit need to understand. By watching the code provided by Microsoft and running it in person, it will have a relatively sensibility to the SOAP Toolkit.
However, it is necessary to remind you that you must have an example of an attached, you must have an IIS service and create a virtual directory and mapping host name as required. See the installation instructions for the Sample page for details (SETUP INSTRUCTIONS).
Seven. Two tools for SOAP Toolkit
WSDL Generator: This tool is the Toolkit itself, the main function is to publish a COM object as a Web Service to the server development.
You only need to specify the COM object and the interface function to be output, and the published URL, the tool automatically generates the corresponding WSDL and WSML files. You only need to copy WSDL and WSML to the corresponding virtual directory, a web service is completed - the tool avoids trouble writing WSDL and WSML, but because the version cannot achieve mapping of complex data types. So if there is a complicated data type, you still have to modify manually.
Web Service Proxy Wizard: This tool is released after Toolkit, so you need to download separately (address see Appendix). The function of this tool is just in contrast to the WSDL Generator, generating a corresponding COM access object for a WSDL file for the development of the client.
You only need to assign a WSDL file to call the WebService, which automatically generates an ATL COM object class (Proxy object). The call to the Web Service can be implemented by calling the generated Proxy object. In this proxy object, the entire SOAP call process is done by calling the underlying interface of the SOAP Toolkit. Moreover, since it is generated a VC's ATL COM Object project, you can modify and build the last COM object. The advantage of using the Web Service Proxy Wizard is that the previous binding can be performed in the call of Web Service, thereby improving call efficiency. Moreover, other modules only need to call this proxy object, you can implement calls to the web service without having to contact SOAP Toolkit. For other call modules, the Proxy object is the remote Web Service, which is nothingordual with a general local call.
Conclusion:
More, we are just a summary of Microsoft SOAP Toolkit 2.0. To be truly mastered, you need to practice. We will introduce a detailed introduction in subsequent articles.
appendix:
Microsoft SOAP Toolkit 2.0 Download address: http://msdn.microsoft.com/downloads/default.asp? Url = / code / sample.asp? URL = / msdn-files / 027/001/580 / msdncompositeDoc.xml
SOAP topic on MSDN:
http://msdn.microsoft.com/soap/
Microsoft SoapSDK newsgroups: http: //msdn.microsoft.com/newsgroups/default.asp url = / newsgroups / loadframes.asp ICP = msdn & sLCID = us & NewsGroup = microsoft.public.xml.soapsdk & frame = true??
Download address of Web Service Proxy Wizard:
Http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs600/html/webservproxwiz.asp?frame=true
VB Web Services Proxy Generator (found on the newsgroup, there is no test)
Http://www.vbxml.com/downloads/default.asp?id=v2001510204034
