Improve company productivity with a Business Account.Sign Up

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2235
  • Last Modified:


I have read "gigabytes" of articles on the net regarding XML, SOAP, Web Services... but I would like a good solid opinion from someone here.

For the purpose of various apps utilizing VB, ASP, and SOAP (ALSO using SSL), what would be the advantage of using the MS Soap Toolkit MSSOAP vs just using SOAP/XML over XMLHTTP and serverXMLHTTP in the MSXML3?  As I said, I have read lots about both, but I want a direct discussion from someone knowledgeable.

I can be generous if I feel extra enlightened!
  • 4
  • 3
1 Solution
Tommy HuiEngineerCommented:
Think of it this way:

You use VB because it hides all the details about programming the CPU using assembly language. You don't want to think about registers or direct memory access. Instead, you think of objects. VB simulates these objects for you.

The same is true for SOAPToolkit compared to XML. XML is the low-level stuff. You will have to know about WSDL and how to interpret the objects passed by SOAP services (Web services) if you used XML directly. You will have to know about how to create SOAP messages. The SOAP Toolkit hides a lot of details for you. If you are doing anything with SOAP using VB, this is toolkit to use.
vbPhilAuthor Commented:
From what I've studied, there is little if anything saved in complexity with the Soap Toolkit.  Manipulating the DOM, XML Documents, and creating SOAP Envelope structures is not a concern.

If I don't have to worry about distributing the Toolkit DLL I'd rather not.  What I am looking for is what technical advantage will I be missing if I do not use the Soap Toolkit?  
Tommy HuiEngineerCommented:
Here's a sample SOAP client application. Notice the simplicity of the program. I would hate to write/debug/test the SOAP messages needed to call the web service. Not that you couldn't but why rewrite the code when you don't have to?

Dim soapClient
set soapclient = CreateObject("MSSOAP.SoapClient")
' On Error Resume Next
Call soapclient.mssoapinit("", "Service1", "Service1Soap")
if err <> 0 then
    wscript.echo "initialization failed " + err.description
    DIM xmlNode
    wscript.echo soapclient.GetQuote("MSFT.O")
end if
wscript.echo "Done"

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

vbPhilAuthor Commented:
Here is a sample client application, using the xmlHTTP object from msxml2.  Except for constructing the SOAP Envelope, why is this any more complex?  As I said, I'm not concerned with how to write the code...

I want to know if there is a Reason in the "underlying technology" to use one or the other.

Dim objHTTP
Dim objReturn

Set objHTTP = CreateObject("MSXML2.XMLHTTP30")
Set objReturn = CreateObject("MSXML2.DOMDocument30")

'Create the SOAP Envelope
strEnvelope = _
   "<SOAP:Envelope xmlns:SOAP=""urn:schemas-xmlsoap-org:soap.v1"">" & _
   "<SOAP:Header></SOAP:Header>" & _
   "<SOAP:Body>" & _
   "<m:GetSalesTax xmlns:m="""">" & _
   "<SalesTotal>" & Trim(txtSalesTotal.Text) & "</SalesTotal>" & _
   "</m:GetSalesTax>" & _
   "</SOAP:Body>" & _
   "</SOAP:Envelope>" "post", "", False
objHTTP.setRequestHeader "Content-Type", "text/xml"
objHTTP.setRequestHeader "SOAPMethodName", ""
objHTTP.send strEnvelope
strReturn = objHTTP.responseText
Tommy HuiEngineerCommented:
Let's say that your SOAP services was updated. It added a new parameter to your function, or maybe even the function has changed name. Using SOAPToolkit, you have to add the new parameter or changed the function name. Using pure XML, you have to change the entire XML document sent over to the server.

I'm saying it is harder because you have to enter more lines of code into your program. Every line you add increases the chance of it not working. It also means that you have to change more lines of code should the server change.

Libraries are created to simplify your life. SOAPToolkit does this by making the SOAP services available to your application as if it were a function call. It has all of the code to serialize your parameters to the proper SOAP type. It handles the deserialization of SOAP objects to the proper COM object. If you don't want this benefit, you would have to write the same code anyway to properly make SOAP requests and handle SOAP replies.

In your case, it is simple because the parameters and return values are simple. What if the parameters expect an object? What if the return value is an object or an array? How much code would you have to write to handle these cases? What if your tax service gets changed to return not just the total, but also the percentage that was used? What if your tax service needs a city and state as its parameter so that it can use the proper percentage?

vbPhilAuthor Commented:
Ok thui...

Still not quite the argument I was looking for.  I understand how components can simplify coding requirements.  What I was looking for was more of a discussion about how MSSOAP interacts with the IIS in ASP, as opposed to MSXML and if either method was better suited to SSL.  Things like that.

But, your comments are well received and since you took the time to have this discussion, you can have the points.

Tommy HuiEngineerCommented:
Sorry, I just recently moved so I have spotty network connections until my DSL is in...

I think I understand better what you're looking for. SOAP is geared towards object communication between a client and a server. You can think of it as a protocol that sits on top of a transport. The transport is determined by you. SOAP can use SMTP (e-mail), HTTP, HTTPS, and anything else as long as there is a handler for the transport. SOAP takes care of serializing the object's state to XML. It passes the SOAP (specialized XML) packet to the transport. SOAP also takes care of deserializing the SOAP packets. SOAP does not care who transport you use, nor does it care about any other technology. Therefore it does not interact with IIS. Although if you did use HTTP, then it must interact with a web server, but it does not have to be IIS.

XML is the underlying technology for SOAP (i.e. SOAP uses it heavily). XML also does not care about transport, in fact, XML itself really does not care about where you get the XML document from. You can create one from scratch, load it from a file or pull it from a database. But MSXML (Microsoft's implementation) has a unique feature in that you can pull an XML file from not just the local disk, but also from a web server. In this one specific case, MSXML and SOAP seems to overlap, but in reality, it doesn't. SOAP when used with HTTP or HTTPS will use the HTTP protocol to retrieve a SOAP packet. The SOAP packet in an XML packet that contains SOAP specific information. MSXML however, will load an XML packet (or document or fragment) from an HTTP server. This XML packet can be any XML packet. Using MSXML, you can then traverse the XML DOM to see what was retrieved. Using SOAP, an object will be returned whereupon you can see what properties it has.

Another aspect to be careful of is that MSXML is client technology. Microsoft does not recommend using MSXML on the server side. For example, you shouldn't use VBScript code in an ASP page that uses MSXML. There would be scalability issues.

Instead, you should use XMLServerHttp. This component provides similar functionality as MSXML to pull an XML document from another server. This component can be used on the server (i.e. within an ASP page).

I hope this addresses your question better.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

  • 4
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now