Microsoft SOAP Toolkit 2.0 Introduction (RPM)

While there are many different implementations of soap, I think it's best for VC/VB programmers to choose the Microsoft implementation. First put aside. NET WebServices (because I'm not familiar with L), we're going to talk about Microsoft Soap Toolkit 2.0.

Microsoft Soap Toolkit 2.0 provides a complete set of COM objects to handle all soap-related data so that you don't understand soap and XML (preferably, of course), It can also be easy and convenient to use any programming language to write SOAP applications. What you see is a COM object (consistent with Microsoft's style, consistent with the programming habits of the average programmer).

I. Introduction to the function:

1. Provides a client-side component that allows you to specify the WSDL and then easily invoke the corresponding web Service.

2. Provides a server-side component that allows you to specify WSDL, WSML, and COM objects to automatically generate Web service for you.

3. It also provides a low-level processing component that allows you to manipulate the process of creating, processing, and transferring SOAP messages.


Two. Several concepts:

WSDL (Web services Description Language): Used to describe the XML format of services provided by the service side. The WSDL file describes the services provided by the server, the invocation method provided, and the format to be followed when invoked, such as the format of calling parameters and return values, and so on. WSDL is much like the IDL (Interface Description Language) in COM programming, the contract between the server and the client, the two sides must act strictly according to the contract to realize the function.
WSML (Web Services Meta Language): Describes the mapping between the methods provided in WSDL and the COM objects that implement the method. This file is specific to the implementation of Microsoft and is not part of the SOAP standard. Typically, the file exists only on the server side.
SOAP messages: Both the method invocation request and the result return value between the client and the server are placed in these messages and are XML-formatted data.

Three. Web Service invocation Process:

Client: Obtain service-side service description file WSDL, parse the contents of the file, understand service-side service information, and how to invoke it. Generate the appropriate SOAP request message (Specify the invoked method, parameters that have been invoked), and send it to the server, as needed. Waits for the SOAP response message returned by the server to parse the return value.
Server side: Generates a service description file for client access. Receives a SOAP request message from the client, parsing the method invocation and the parameter format. According to the WSDL and WSML descriptions, the corresponding COM object is invoked to complete the specified function and the return value is returned to the user in a SOAP response message.
Four. Two modes of programming
High-level interface
With high-level interfaces, you don't need to know anything about soap and XML to generate and use a webservice. Soap Toolkit 2.0 accomplishes these functions by providing two COM objects ――soapclient and soapserver.
On the client side, you only need to generate a soapclient instance and use the WSDL as a parameter to invoke the MSSoapInit method. The SoapClient object automatically parses the WSDL file and generates the method and parameter information for all Web service internally. After that, you can call all the methods in the same way as you would call the IDispatch interface. In VB or scripting language, you can even add directly to the SoapClient object name. Method (Parameter ...) Make a call.
On the server side, there are two modes of processing. One is to generate an ASP file, and the other is to use the ISAPI extension directly to make the DLL provided by the SOAP Toolkit handle the WSDL request.
In the first model, you need to create the SoapServer object in the ASP file, invoke the Init method with WSDL and WSML as parameters, and SoapServer automatically establish the related mapping relationship internally. The Soapinvoke method is then invoked using the ASP's request and response objects as parameters. SoapServer automatically obtains the user's SOAP request message from the request, resolves it, invokes the corresponding COM completion function, encapsulates the return value into a SOAP response message, and returns it via the response object.
In the second mode, the ISAPI extension provided by the SOAP Toolkit automatically completes all of the above ASP mode.
The comparison between the two modes is that the first one is more flexible, but the speed is slow. The second, although not flexible, but the performance is very high. So, if you don't have a special, use ISAPI mode.
Low-level interface
To use low-level interfaces, you must have an understanding of soap and XML. You can control the process of soap processing, especially when it comes to special processing.
On the client side, you first create a HttpConnector object that is responsible for the HTTP connection. Set up some connector header information, such as Endpoinurl and SOAPAction. If the network connection needs to use a proxy server, then also set up the relevant information here. The Soapserializer object is then created to generate the SOAP message. According to the WSDL definition, all parameters are serialized sequentially, and a complete SOAP request message is obtained. The SOAP message, as payload, is sent through the HttpConnector to the service side. Finally, a Soapreader object is generated that reads the SOAP message returned by the server and obtains the return value.
On the server side, the input and output of HTTP connection are obtained first through the request and Response object in ASP. It then creates the Soapreader object, reads the SOAP request message in the Request object, resolves the parameters of the method and invocation to be invoked, executes the actual call, and obtains the execution result. Finally, a Soapserializer object is generated, which serializes the execution result as described in WSDL, generates a SOAP response message, and returns it to the client via the response object.

Five. Questions and Answers

Why should there be WSML?
A: Because soap itself is only a protocol to object access, the way it is implemented is not specified. In general, using SOAP is the ability to expose the functionality of existing systems to the outside world in a standard way so that outsiders can access them. On the platform of Microsoft, for the interoperability of the module, the realization of the function is generally provided in COM way. And how to map the method described in WSDL to the COM interface method, which is what WSML to do. Now you can see that using WSML, you don't have to do much work, you can quickly turn existing applications into Web service applications. On the server side, you have completely retained Microsoft's com/com+ application model. (Of course, WSML is also not necessary if you do not need to use COM's method mapping.) If you don't use the SOAP Toolkit high-level interface, use the underlying interface. That's not necessary. ）

How do I handle complex data types?
A: You can implement a custom type mapping COM object (custom type Mapper) and specify it in WSML. In this way, the SOAP Toolkit will call this mapper to process the messages in the SOAP message during processing. For example, to return a complex data, on the server side, toolkit to know how to serialize a complex data type into an XML node. On the client side, toolkit to understand how to reuse XML nodes as a complex data structure.
It is important to note that this mapping object (Mapper) is not required, but is used for ease of use. In other words, the two sides will be able to achieve the success of the call if they strictly follow the specification described in the WSDL. Regardless of how your client and server map this complex data type, it is a C structure, a COM object, or a Java class, which is irrelevant.

Six. Examples of SOAP Toolkit

The example of Toolkit is already very comprehensive and explains the various invocation methods that need to be understood to use this toolkit. By looking at the code provided by Microsoft and running it yourself, you will have a more perceptual understanding of the SOAP Toolkit.
However, you need to be reminded that if you want to run the accompanying example correctly, you must have the IIS service installed, and also create the virtual directory and map hostname as required. Please see the installation instructions (Setup instructions) for the sample page.

Seven. SOAP Toolkit two Tools

WSDL Generator: The tool is toolkit, and the main function is to publish a COM object as a Web service for server development.
As long as you specify the COM objects and the interface functions to be exported, and the published URLs, the tool automatically generates the corresponding WSDL and WSML files. All you have to do is copy the WSDL and WSML to the corresponding virtual directory, and a Web service is done----The tool avoids the hassle of manually writing WSDL and WSML, but because that version is not yet able to implement a mapping of complex data types. So if you have complex data types, you will have to modify them manually.
Web Service Proxy Wizard: The tool was released after toolkit, so you'll need to download it separately (see appendix for the address). The tool completes a function that, contrary to the WSDL generator, generates a corresponding COM Access object for a WSDL file for client development.
The tool automatically generates an ATL COM object class (proxy object) whenever you specify that you want to invoke the WebService WSDL file. A call to a Web service can be implemented by invoking the generated proxy object. In this proxy object, the entire SOAP invocation process is accomplished by invoking the underlying interface of the SOAP Toolkit. Also, because you are generating a VC ATL COM object Project, you can modify it and compile it to generate the final COM object.
The advantage of using Web Service Proxy Wizard is that it can be used to bind to a Web service invocation, thereby increasing the efficiency of the invocation. Furthermore, other modules need only invoke this proxy object to implement a call to the Web service without any direct connection to the SOAP Toolkit. For other calling modules, the proxy object is that remote Web Service, which is no different from a typical local call.

Eight. Conclusion:

Above, we just made a brief introduction to Microsoft SOAP Toolkit 2.0. To really grasp, but also need to continue to practice. We will give a detailed description of how to implement this in a subsequent article.

Appendix:

Download address for Microsoft Soap Toolkit 2.0: http://msdn.microsoft.com/downloads/default.asp? Url=/code/sample.asp?url=/msdn-files/027/001/580/msdncompositedoc.xml
Soap topics on MSDN:
http://msdn.microsoft.com/soap/
Microsoft SOAPSDK News Group: Http://msdn.microsoft.com/newsgroups/default.asp?url=/newsgroups/loadframes.asp? Icp=msdn&slcid=us&newsgroup=microsoft.public.xml.soapsdk&frame=true
Download address for 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 newsgroups, not tested)
http://www.vbxml.com/downloads/default.asp?id=v2001510204034