I need to consume an external web service from my VB6 program. I want to be able to deploy my program without the SOAP toolkit, if possible, but that's not a requirement. I do not have the web service source and I didn't create it. It is a vendor-provided service.
So outside of the SOAP toolkit, what is the best way to consume a web service from VB6?
I use this function to get data from a web service.
Private Function HttpGetRequest(url As String) As DOMDocument
Dim req As XMLHTTP60
Set req = New XMLHTTP60
req.Open "GET", url, False
req.send ""
Dim resp As DOMDocument
If req.responseText <> vbNullString Then
Set resp = New DOMDocument60
resp.loadXML req.responseText
Else
Set resp = req.responseXML
End If
Set HttpGetRequest = resp
End Function
.NET has a good support for Web Services since day one, so you can develop your Web Service client logic in .NET as a .dll library/assembly and use it in VB6 app via COM Interop.
Assuming that you're running on Windows XP Professional or above, one interesting method is to use the SOAP moniker. Here's an example, lifted from some MSDN page. I don't know if this particular service works, but you get the idea...
set SoapObj = GetObject
("soap:wsdl=http://www.xmethods.net/sd/TemperatureService.wsdl")
WScript.Echo "Fairbanks Temperature = " & SoapObj.getTemp("99707")
This mechanism also works from VBScript. Which is nice.
Pocketsoap works very well. To generate your objects use the WSDL generator. Using this you don't have to parse anything yourself, plus everything is nice and strongly typed.
Check out this article by Scott Swigart on the MSDN VB 6.0 Resource Center.
Calling Web Services from Visual Basic 6, the Easy Way
I've had some measure of success so far using PocketSOAP to connect to the Salesforce API. I could not use the WSDL Wizard because it generates wrapper class filenames using the first 23 characters of the call names, and this results in duplicates. Nevertheless, PocketSOAP has been working well enough for me without the wizard, and it's much more straightforward than using XMLHTTP with DOMDocument.
I also looked into making a wrapper in .NET or using one of the "MS Office {MSO version} Web Services Toolkit" libraries, but there were significant deployment hassles with those options. PocketSOAP is a simple COM DLL, not dependent on some particular version of MS Office, and is licensed under MPL.
The SOAP toolkit is arguably the best you could get. Trying to do the same thing without it would require considerable extra effort. You need to have quite serious reasons to do that.
The format of the SOAP messages is not really easy to read or write manually and a third-party library is highly advised.
Related
I want to call a rest service written in WCF (which can support both XML and JSON Web Message Formats) from my C++ application.
What is the best solution to achieve this ? I have seen some utilities (gsoap) which create proxy classes for you to be used to call web services.
Can I achieve the same functionality without using any intermediate utility ? As its a rest service and it works using GET/PUT functions which are basic HTTP functions, is there any C++ library/Solution which could be used to invoke these function directly from a c++ application ?
On Linux, you probably could use curl library (and I guess it is ported to Windows). Curl is a library providing HTTP client functionality to a C or C++ program.
Use Casablanca. This should be helpful for people looking for this answer in 2013. CURL is perfectly appropriate but if you're doing C++ in Windows and using MS stuff, Casablanca seems fit.
Hope the following articles might be of help to you
1. Accessing an XML Web Service Using C++
2. SOAP client for C++
I tried gsoap myself but it became difficult to maintain cross platform versions of my app.
Instead i went the HTTP request route.
For cross platform and C++ i found this Call Rest Web Services from C++
If XML serialization with your REST approach is really not needed then curl is perfect to use. However, if you want type-safe XML serialization in C or C++ then it would become cumbersome to use curl, since you will have to use something that runs on top of curl to process XML such as with a DOM parser (slow and not type safe). If you have a WSDL, then I recommend gSOAP 2.8 which provides integrated REST and XML serialization capabilities (and JSON when you need it).
okay this might be a pretty lame and basic question but its stuck in my head since i never had chance to work on web-services.
We can get the same "text bases" response(xml, json etc) from our server by very basic/simple implementations (lets say servlet) then why do someone has to develop a web-service.
What is the exception thing a web-service gives over simple http response?
At a basic level, you are quite correct, from a low level point of view, it's just text (XML) on a socket.
For simple web services, a servlet is adequate (I'm writing one of these as we speak).
When talking about something like SOAP and WSS-* web services, however, there is a lot of boiler plate processing and features available from the standards that web service toolkits expose as higher level transactions.
A simple example is data marshaling. If you treat it purely as XML, then your service basically gets to process the XML by hand -- parse it, evaluate it, populate your internal models, etc.
Contrast this to something like this from Java EE:
#WebService
public Person getPerson(String personId) {
Person p;
...
return p;
}
The web service stack will convert your Person object in to a SOAP compliant XML blob. It will also produce a WSDL that you can use to create client code (on many platforms: .NET, PHP, etc.) to make the web service code.
In the end, your client and server have only a few lines of code, while the frameworks do all of the grunt work parsing, marshaling, and publishing for you.
So, the value of the WS stack is that it handles much of the bureaucracy of writing WSS compliant web services.
It's no panacea, but for many modern implementations, SOAP <-> SOAP remote processing can be a, mostly, cross platform, drag and drop affair.
It depends. If your web service needs to answer a simple yes/no question like "does this username exist?", then return yes, no, 0, 1, etc may be enough. If you have one that returns all the faculty attributes, XML or JSON may be appropriate because of the structured nature. It's a little less prone to parsing errors than trying to parse plain text.
Does anyone know of any really good C++ Libraries for implementing a web services api over top of existing legacy code?
I've got two portions that are in need of it:
An old-school client/server api (No, not web based, that's the problem)
An old cgi application that it integrates with the client and server.
Let me know if you've had any luck in the past implementing something like this using the library.
Microsoft has put out native code webservices API (WWSAPI) that looks pretty decent. I haven't had a chance to use it yet. We had originally ignored it, since it required Windows 7 or Server 2008, but they've finally released a runtime library for older OSs.
I would advise staying away from Microsoft's old SOAP SDK. For one, it's been deprecated; two, it's not terribly easy to distribute; and three, it's terrible to code for compared to the .NET offerings.
What we've done is written a bit of C++\CLI to interface our existing C++ codebase with .NETs webservice framework. This turned out to be remarkably easy. .NET will generate all the classes and boilerplate code you need based of of a WSDL file. Then you just write some C++\CLI code to handle the incoming data as managed classes and fill in some managed classes as responses.
You can use the Apache AXIS/C interface to build a web services interface. It has plugins for Apache and IIS (and I think FastCGI), and lets you talk web services to your legacy code.
I used gSOAP in a project and it was quite straightforward. Compared to Axis/C, I found it easier to learn and use. I never used POCO, can't give you an opinion, but it's gaining popularity recently. This is the link for gSOAP
http://www.cs.fsu.edu/~engelen/soap.html
We have a three-tier architecture consisting of Classic ASP Frontend, VB COM+ Objects and MSSql Database.
We are going to replace the VB COM by ASP.NET Webservice layer soon but we are not in the position to replace the Classic ASP with new .NET code (yet) and we're therefore going to need a way to consume webservices in Classic ASP...
We know it's possible but unsure what the best way is to do this...
Can we return VBScript RecordSets in a webservice call? (All of our Classic ASP Frontend uses Recordsets at the moment). If not what would the easiest way to use consume the results?
Are there any libraries / classes that make it easier?
All advice, links, code examples and comments are welcome!
Here is an article on codeproject which should solve your problem.
I suggest that you write a .NET client and compile it with a COM interface so that you can invoke it from classic asp just like any other COM component.
Depending on what your webservice returns/requires you may need to write a layer around the the .NET client to make the input\output VB Script friendly. If you are using recordsets in your VB code you could fabricate these inside this layer.
Since it's a Webservice, is there a reason to avoid using ASP.NET for just that layer?
It is certainly possible to return a recordset using VBscript, but I'm not sure why you would want to go this route since you would have to convert the recordset to XML, etc.
Just kicking this out in VB.NET, which is extremely well documented, will probably take less time and energy than all of the crazy debugging you will end up doing in VBScript.
There is a Microsoft SOAP client COM component you can use in ASP/VBScript, called MSSOAP.SoapClient, you can get it here - http://www.driverskit.com/dll/mssoap30.dll/2342.html
I don't think MS is particularly supporting this component anymore, the link to the download on their site now redirects to the WCF home page. You'd have to dig for some documentation on it's use as well...
Note: not ASP.NET.
I've read about various methods including using SOAPClient (is this part of the standard Windows 2003 install?), ServerXMLHTTP, and building up the XML from scratch and parsing the result manually.
Has anyone ever done this? What did you use and would you recommend it?
Well, since the web service talks XML over standard HTTP you could roll your own using the latest XML parser from Microsoft. You should make sure you have the latest versions of MSXML and XML Core Services (see Microsoft Downloads).
<%
SoapUrl = "http://www.yourdomain.com/yourwebservice.asmx"
set xmlhttp = CreateObject("MSXML2.ServerXMLHTTP")
xmlhttp.open "GET", SoapUrl, false
xmlhttp.send()
Response.write xmlhttp.responseText
set xmlhttp = nothing
%>
Here is a good tutorial on ASPFree.com
We use the MS Soap Toolkit version 3 here. Seems to work ok (I only wrote the services).