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).
Related
I have a SOAP server API for some of our services and one of the clients said that they won't integrate with services not offering at least WS-I Basic Profile compliance binding.
So, the question is does any version of Delphi support Document/literal or RPC/literal binding?
Edit: Looks like RemObjects support Document/literal or RPC/literal.
I recently dove into the Delphi code because I could not consume the MS Exchange Server WDSL (which seems to be SOAP 1.1 "document/literal wrapped").
I'm not an expert in this, but I came across this code in the Delphi XE2 unit Soap.OPToSOAPDomConv which does not look correct to me:
if not IsRPC then
begin
if IsBareLiteral then
begin
[snip]
end
else
begin
// IsWrappedLiteral !
with
function TSOAPDomConvHelper.IsRPC: Boolean;
begin
Result := not (soDocument in Options);
end;
function TSOAPDomConvHelper.IsBareLiteral: Boolean;
begin
Result := Options * [soDocument, soLiteralParams] = [soDocument, soLiteralParams];
end;
function TSOAPDomConvHelper.IsWrappedLiteral: Boolean;
begin
Result := Options * [soDocument, soLiteralParams] = [soDocument];
end;
Although your question is about WSDL generation (not about its consumption), the above suggests to me that "document/literal wrapped" is not properly supported.
Jan
From MSDN (April 2003):
WS-I Basic Profile and RPC/literal
Unfortunately, the WS-I Basic Profile explicitly permits the use of
both document/literal and RPC/literal. Given the above analysis, I
believe having two message formats is unnecessary and ultimately does
not help interoperability. Hopefully, most if not all Web service
developers will ignore RPC/literal and provide the necessary feedback
to WS-I to fix this in a future version of the Basic Profile.
So I would suggest to ignore RPC/literal completely.
Also http://en.wikipedia.org/wiki/WS-I_Basic_Profile points to different versions of WS-I Basic - 1.2 (finalized in November 2010) and 2.0 (published in November 2010) seem to be the latest versions. I would check which version level is expected from your communication partner.
Solution
Move the web service from Delphi to a WS-I compliant framework, with Delphi still providing the logic but talking internally over IPC with the new framework.
The majority of the compliant frameworks listed in the Wikipedia article are open source, have good documentation and a huge installed user base, so they are production-ready and stable.
In the long run, using a compliant framework will cause less hazzle and workarounds, and also allow to support the other WS-I standard with little additional work.
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).
I've got a Web Service written using C# in Visual Studio 2008 (I've also written it in VS 2005).
I can write a test windows form app to consume the service no problem.
The problem I have is consuming it from C#/VS2003 (or php which is my real problem). It just gives me the error:
"Cannot implicitly convert type 'TestIntel.WebIntel.GetSitesResponseGetSitesResult' to 'System.Data.DataTable"
The Web mthod does return a DataTable; as I said this works fine if the consumer was built in VS2005/2008. What gives?
In order to consume a DataTable, the calling points (php and .net 1.1) need to know how to deserialize it into usable object.
This means that they would have to have a similiar object that the data can be deserialized into.
Obviously, PHP can't do that. And the reason for the .net 1.1 error is that the DataTable object changed quite a bit between 1.1 and 2.0. In fact, Microsoft says that the .Net 1.1 datatable object is BY DESIGN not supposed to be serialized through a web service. ( [http://support.microsoft.com/kb/306134][1] )
If you are looking for a real cross language way of doing this then you need to serialize your response into a standard XML object. Which could be parsed correctly by any language. This is a little more work, but results in a usable service.
My experience to write a plugin for Firefox is below zero. Is someone out there who could point me to sample code on how to get this accomplished in C++ with VS2005/8?
What I need to do with JavaScript in the hosting html page is something like this:
var obj = document.getElementById("MyFFPlugin");
var value = obj.CalculateValue;
// Work with calculated value
The SDK has basic samples on how to write mozzila plugins which can be downloaded here: http://mxr.mozilla.org/seamonkey/source/modules/plugin/tools/sdk/
Here is the official mozilla plugin site http://www.mozilla.org/projects/plugins/
Hope it helps.
I highly recommend using Nixysa http://code.google.com/p/nixysa/, which wraps NPAPI. From the site:
Nixysa is a framework written in
Python to automatically generate glue
code for NPAPI plugins (plugins for
browsers such as Google Chrome or
Firefox), letting you easily expose
C++ classes to Javascript from a
simple IDL representation. Nixysa was
originally conceived for the needs of
O3D, but is flexible enough to support
a wide range of use cases.
Try it
Check out the code following the
instructions here and try the sample
in examples/complex.
The sample includes a Visual Studio 2005 project.
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.