September 6th, 2011
How do you get the debugger in Zend Studio to step through SoapServer code?
Inevitably as you develop Soap services with PHP you have to deal with a bug in the server side code. Since you can embed SoapClient in a script that renders a Web page and hit said page from a browser, it’s easy to debug SoapClient code using the debug toolbar. Doing the same for SoapServer code doesn’t work; you’ll see the problem in a moment. Conventional techniques like error_log et al to track down problems can seem painful compared to Zend Studio’s interactive debugger. Once you’re comfortable with the debugger and the advantages it offers this SoapServer enigma becomes very annoying, especially when you’ve got a bug to fix!
May 3rd, 2011
If you read our article a couple weeks back about dynamically changing the WSDL URL via SoapServer you may have thought, there’s little value here, since I use Zend Framework or NuSoap to publish Soap Services with PHP. This article explores a more prevalent issue with the design of SoapServer and the problem can’t be solved with a subclass of SoapServer. The problem we explore in this article is the design of the classes you would use to handle Soap actions. These classes and objects are designated by the SoapServer setClass and setObject methods. We’ll refer to them as Provider Classes in this article.
April 9th, 2011
Services need to be portable
So you’ve started using PHP’s SoapServer class with hand built or pre-generated .wsdl files. Great, you’ve got a Soap service running on a development machine! Upon deploying the service in a different environment clients are submitting requests to the development machine, what happened?