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
