If its based on soap/ext then it probably will not work for our service either. Soap/ext choked on namespaces pretty badly, which is used extensively by our service. I'll play with it an let you know.
-e On 7/3/08 8:04 AM, "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 <[email protected]> > 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 > > >
