Using Doctrine2 for your new Zend project and Migrations 2.0 for database versioning? One aspect that quickly becomes annoying is the lack of integration with the standard Zend application.ini. Yes there is –configuration which allows you to specify configuration options via xml or yml, but those files aren’t aware of the many environments your Zend application is likely deployed to, nor do they know about handy shortcuts like APPLICATION_ENV, forcing you to hardcode absolute paths in each of several configuration files (one per environment).
A few months back we posted an article about a limitation in the design of SoapServer and it’s cousin Zend_Soap_Server. Zend_Amf_Server has a similar problem, namely no way to log input parameters and output results for service calls. As mentioned previously, being able to log inputs and outputs from a central location is a huge boon. The good news is Zend_Amf_Server does the protocol marshalling entirely in userspace so it’s much easier to accomplish this time around.
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.
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?