For our Web-Portal superspeed, I am working on a webservice to give some clients access to our provider/offer database.
As the whole portal is written in PHP, I deceided to write the Webservice (fully fledged using the SOAP-Protocol) in PHP too. After some searching, found NuSOAP and the SOAP-Package in PEAR.
Both packages have virtually no documentation, but the PEAR-package has some nicely documented samples (disco_server.php, example_server.php just to name the most interesting two).
While nuSOAP is very easy to handle, it doesn’t have a way to autogenerate WSDL-output which would have forced me to learn writing WSDL. Unfortunatly I did not have time for this, so I went with the PEAR-Package which is able to create the WSDL for you.
The first tests using PHP as SOAP client worked very well.
tip: to increase “debugability” to an actually useful level, use something like the code here for debugging your server:
// include the actual server class
require_once 'modules/ss3_Provider/xml_access.php';
if ($_SERVER['argv'][1] != 'direct'){
// use the SOAP-Interface to our class
include("SOAP/Client.php");
$wsdl = new SOAP_WSDL("http://your.server.com/server.php?wsdl");
$object = $wsdl->getProxy();
}else{
// Use the class directly
$object = new CProvServiceInfo_Class();
}
// do something with $object
If the script is called with the “direct” parameter, the class will be used directly thus giving you back all the debug information you need without an XML-parser trying and failing to unserstand them.
As the customer for this service is going to use ASP.NET to access the webservice, the next step was to try accessing the service via Visual Studio.NET. This was not fun (pasting the complete error here in the hope that google will catch this and will help future users having my problem):
Custom tool warning: At least one import Binding for the ServiceDescription is an unsupported type and has been ignored.
The hairy thing: I have no expirience at all with VS.NET, so I first thought this was a minor problem and I was just too stupid to actually use the imported class. But sooner or later (after trying out importing the Google Webservice), I came to the conclusion that this warning actually is a grave error: Nothing got imported. Nothing at all.
Searching google did not yield any results.
The next step for me was to learn WSDL (which I did not want to in the first place ;-). Unfortunatly, the PHP generated WSDL-File seemed quite ok (besides the missing <documentation>-Tags).
I could not get VS to report a mor detailed/useful error message.
Just when I wanted to give up, i thought of this tool, wsdl.exe that gets installed with the .NET Framework SDK. Running wsdl <filename.wsdl> gave me the same error message, but with a note to look into the generated .cs-File.
This finally gave an usable error-message:
// CODEGEN: The binding 'SuperspeedProvidersBinding' from namespace 'urn:SuperspeedProviders' was ignored. There is no SoapTransportImporter that understands the transport 'http://schemas.xmlsoap.org/soap/http/'.
A quick comparison of the <soap:binding>-Tags showed:
Googles Version: http://schemas.xmlsoap.org/soap/http
PHP’s Version: http://schemas.xmlsoap.org/soap/http/
Note the slash at the end.
I hate problems with simple solutions that are so awfully difficult to find because of un-usable error messages!
Just for reference: The following patch fixes the wrong Transport-URL in PEAR::SOAP (0.7.3 – I will report this to the author, so maybe it’s fixed in later versions):
--- Base.php Thu Jun 5 13:16:03 2003
+++ - Fri Jun 6 22:51:08 2003
@@ -91,7 +91,7 @@
define('SCHEMA_DISCO_SCL', 'http://schemas.xmlsoap.org/disco/scl/');
define('SCHEMA_SOAP', 'http://schemas.xmlsoap.org/wsdl/soap/');
-define('SCHEMA_SOAP_HTTP', 'http://schemas.xmlsoap.org/soap/http/');
+define('SCHEMA_SOAP_HTTP', 'http://schemas.xmlsoap.org/soap/http');
define('SCHEMA_WSDL_HTTP', 'http://schemas.xmlsoap.org/wsdl/http/');
define('SCHEMA_MIME', 'http://schemas.xmlsoap.org/wsdl/mime/');
define('SCHEMA_WSDL', 'http://schemas.xmlsoap.org/wsdl/');
As you can see, there are more URLs having a slash at the end – possibly more candidates? We’ll see. At least I know now, how to debug such problems…
gnegg 