SOAP support

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

SOAP support

Alexander Veremyev
Hi all!

I'm very glad to announce promoting initial SOAP support implementation
from the incubator to the standard library.

Documentation is provided and should completely describe how to use it.
Unit test may also give an idea how to do this.


It's planed to include SOAP support into ZF 1.6 and ZF 1.6 RC1.

API still may be changed before the GA release, so it's good time for
testing and giving your suggestions.


I would also like to ask you to perform compatibility tests against
other SOAP implementations (.Net, JEE, ...).


With best regards,
   Alexander Veremyev.
Reply | Threaded
Open this post in threaded view
|

Re: [fw-general] SOAP support

James Dempster
Ooo very interesting Alaxander, thanks I will be checking this out (svn and looking at) tomorrow.

Thanks! :)

/James Dempster

On Wed, Jul 2, 2008 at 7:10 PM, Alexander Veremyev <[hidden email]> wrote:
Hi all!

I'm very glad to announce promoting initial SOAP support implementation
from the incubator to the standard library.

Documentation is provided and should completely describe how to use it.
Unit test may also give an idea how to do this.


It's planed to include SOAP support into ZF 1.6 and ZF 1.6 RC1.

API still may be changed before the GA release, so it's good time for
testing and giving your suggestions.


I would also like to ask you to perform compatibility tests against
other SOAP implementations (.Net, JEE, ...).


With best regards,
  Alexander Veremyev.

Reply | Threaded
Open this post in threaded view
|

RE: [fw-general] SOAP support

Alexander Veremyev
In reply to this post by Alexander Veremyev
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" <[hidden email]> 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 &lt; &gt; &amp;.
>         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 <[hidden email]>
> To: Zend Framework <[hidden email]>
> 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