Hi Ionut! Great thanks for your review and suggestions for Zend_Soap_Client!
I made some updates of the Zend_Soap_Client. It provides getters and setters for all options now. It also automatically refreshes SoapClient object if any option is updated. I still think about other suggestions you made. Especially about idea to have "Raw Client". I'm not sure we will get fast enough solution if we implement SOAP processing at PHP level (because of string processing speed). On the other hand it's generally XML processing which may be done at the level of one of XML management extensions. Different client behavior may be implemented by extending existing Zend_Soap_Class now. It should use client class extended from SoapClient with overloaded __doRequest() method (which performs optional request/response preprocessing). So there will be several classes for different compatibility modes (ex. Zend_Soap_Client_DotNet, ...) There still exist two opposite goals for Zend_Soap: 1. Make base API simple and clear (also for different compatibility modes), it should take 10 minutes for newbie to get working Web Service server or client compatible with base SOAP implementations (without going into SOAP details). 2. Make it flexible, since almost every SOAP implementation has some differences :/ With best regards, Alexander Veremyev. On 7/3/08 4:04 PM, "Ionut Gabriel Stan" <[EMAIL PROTECTED]> wrote: > I took a look at this package, especially Zend_Soap_Client as right now > I'm involved in developing some SOAP consumers. > Before I go any further I should mention that these are my first SOAP > projects so I'm not that versed in this field. > So... in my opinion and at this moment I see no real benefit in using > Zend_Soap_Client over PHP's builtin SoapClient class. > > > 1. Problems I see so far: > > Matthew once said that a Zend_Soap_Client should be a wrapper for > SoapClient, which more or less will get all the options that one > can pass to SoapClient constructor and provide them getters and setters, > basically giving them ZF-like interfaces. > > a) First problem: Zend_Soap_Client does that but only partially and > is not sticking to a common interface. > For example, in Zend I can't toggle the value of the *trace* > options. I understand this is because > Zend has two methods that count on this: getLastRequest and > getLastResponse, but I assume tracing > requests and responses adds a little bit of overhead that one > might want to avoid in production. Then, why > do we have these two methods but not getLastRequestHeaders and > getLastResponseHeaders? > Again, altghough we don't have them, the presence of the __call > magic method inside Zend makes the two reachable. > There are missing options, like stream_context, features, > cache_wsdl, user_agent and typemap. > There is getFunctions() but not getTypes(). > If I can't have access to all these options, then at least give me > access to the internal SoapClient > > About the common interface, some of the options can be set by > using setters, some only in bulk mode, by passing them > to the constructor or to setOptions(). > For some of the options there is possibility for exceptions, > although in cases where > I don't see that much need for such a strict check (Ex: > setEncoding checks if the passed parameter is a string). On the > other hand, other string options do not get this treatment. > Options names should be standardized. setOptions() allows me both > soapVersion and soap_version, while getOptions only > returns soap_version. > > b) A big problem of SoapClient, in my opinion, is that I can't change > the values of the different supported options between consecutive calls. > It's a function with lots of parameters in disguise of a class. > It would be nice if Zend could do this, although I'm not so sure > how useful this might be. > One way to do this is that, at every call to a remote service, the > soap object to be reinitialized. Another one I see is to > use __soapCall() every time a call is made, but this is harder or > impossible in WSDL mode. > > c) The *biggest* problem of SoapClient is that it doesn't give me > access to the *real* raw DOM. Not even with getLastResponse() > and getLastRequest() or __doRequest(). Why am I stressing the word > real? Because, a few days ago, I noticed that any request I > made with SoapClient to a specific WS returned null and > getLastResponse() returned... some sort of XML. > After scratching my head, reading docs on the php.net manual and > even PHP source code, > I finally noticed that our partners sent us the return value of > the method wrapped inside a CDATA element... > How does SoapClient treats that? It encodes special characters > inside CDATA, ex: <, >, & becomes < > &. > While this might be correct (or not), because I'm sure returning > the whole response inside CDATA certainly isn't, it doesn't help me. > So, Zend should offer access to the real DOM if it wants to be a > useful and extensible library that can overcome any situation out there. > > > 2. Suggestions I have so far: > > a) Until ext/Soap gets better Zend_Soap_Client should be a factory > for a Zend_Soap_Client_Builtin and a Zend_Soap_Client_Raw, where > Builtin in is the wrapper for SoapClient and Raw uses > Zend_Http_Client for sending and receiving data. A Zend_Soap_Client_Raw > should > be very simple, in that it should provide the general message > skeleton (Envelope + HTTP headers) and ways to inject > payloads (Header, Body, Fault?) inside it, where a payload could > be an xml string or a > > DOMDocument/DOMNode/DOMElement/DOMDocumentFragment/SimpleXMLElement > object. It should also be able to > schema validate the message before sending a request and it > should support compression. > b) You should focus more on argument passing and return values. At > this moment, with SoapClient things get a little bit messy > when passing or getting complex types. > Some of the people have no idea how to set attributes for > different XML tags with the current API of SoapClient, > and it's ok, because it's counter intuitive and sometimes > impossible. > I feel better diving into the DOM API than what we have so far > inside ext/Soap. > > > Well, that's what I have to say about Zend_Soap_Client in its current > implementation. > > Ionut > > > > > > ----- Original Message ---- > From: Eric Marden <[EMAIL PROTECTED]> > To: Zend Framework <fw-general@lists.zend.com> > Sent: Wednesday, July 2, 2008 10:36:42 PM > Subject: Re: [fw-general] SOAP support > > > I'm very glad to announce promoting initial SOAP support implementation > > from the incubator to the standard library. > > Where can I get this? > > I'd like to test it against a BPEL generated service we use internally > that > has caused all other PHP packages (Soap/ext, wsf/php, nusoap, pear:soap) > problems in one way or another. So much so that I used the Zend HTTP to > pass > raw xml back and forth. > > -e > > > > > No virus found in this incoming message. > Checked by AVG. > Version: 8.0.134 / Virus Database: 270.4.3/1529 - Release Date: 01.07.2008 > 19:23
