SOAP and PHP: your experience

[NativeMind]

Hey,

I just wanted to get some opinions on people who have used one of the PHP SOAP packages.

I'll start off by sharing my experience:

- NuSOAP: was my first choice a couple years ago, but I don't see any updates on this in a long long time. In fact, nothing on NuSphere's page talks about SOAP other then their wizard in their IDE. Even so, it appears to get the job done for simple tasks, and it's API is more straight forward. The only documentation I can find is simple and outdated tutorials on how to use it with Amazon/Google

- PEAR SOAP: Recommended to me as the best choice until php5. The API will be similar to the PHP5 API, but not the same so expect some churn in my projects later. The main gripes about it are a lack of support for digest authentication, no full WSDL support (ie doesn't support the choice tag for defining an array of mixe data types).

One gotcha when developing a pear soap server is how everything is an array.... Let me give you an example. A normal parameterized method has an array of parameters, and those parameters are easily just an array of name value pairs. For a SOAP array, it's a nested array. For a struct it's an array. For an array of SOAP structs, it's a nested array of arrays ..... which looks like a lot of looping through to get elements out. I would be interested in suggestions here.

- PECL SOAP (formerly known as php-soap on sourceforge)... I *think* this is being worked on as the default SOAP implementation for php5. Recently I have seen it appear in the php manual under web services, but noted as experimental. Unfortunately for me I can't use php5 or experimental soap stuff at work. I haven't heard anything on its features (digest authentication support, WSDL support, etc), but I would be interested to see what's coming down the road.

[kaimeder]

uhm ... i dont like SOAP ...
there are some case studies regarding the different soap-implementations ..
as far as i know some big companies (i forgot the names ... omg) uses the nuSoap instead of pear::soap ... i think this "tells its own tale" .

but personally i would prefer the pear-implementation due to its support.
although i have a big antipathy against pear ... i hate these heavy bloated classes ... but in this case i would use pear.

additionally i think nuSoap lacks some WDSL capabilities pear provides ...

btw, i STRONGLY recommend the REST-style
http://www.xfront.com/REST-Web-Services.html

[Widow Maker]

Yet to really look at Web Services but if your looking for comments etc IMO I'd wait until PHP5 is finallaly released and there are a number of hosts with the PHP5 instal.

That's what I'm thinking about anyways. PHP5 is going to make such a difference not only to use developers, but to business on the Net in general.

Be aware Microsoft

[kuato]

I prefer XML-RPC especially the Incutio library which makes the whole process so damn easy. You have to love the simplicity of an API that is described here: http://scripts.incutio.com/xmlrpc/manual.php

REST is interesting also, I'm just starting to learn about it.

[NativeMind]

i think rest and xml-rpc are great for simple tasks and some website services, but things like embedded applications often need the more advanced things you can do with SOAP.

Also the plethura of SOAP tools/development kits/etc are a big sell for me.

[Travis]

One nice thing about using XML-RPC in PHP is that I believe there is a script that turns a class into a XML-RPC service. I'll have to dig into Google a little harder to look for it if no one else here knows what I am talking about.

[NativeMind]

Pear SOAP does that as well....

[dagfinn]

btw, i STRONGLY recommend the REST-style
http://www.xfront.com/REST-Web-Services.html

The idea of simply sending a plain URL and getting back XML as a simpler alternative to SOAP is a good one. But the rest of REST (the nouns and verbs stuff) looks to me like academic over-fixation on a specific abstraction.

[csn]

I use nuSOAP. Works great and is a piece of cake to use.

[HarryF]

This is big news: http://www.php.net/soap - now in PHP5 RC1. From being an extension that was never going to be finished, it's suddenly gained a ton of functionality, in about three months - take a look at the CVS.

Implementing SOAP in C is going to be fast but you potentially open yourself to having to implement a whole load of other specs. For example, I see it has it's own HTTP client. Do you introduce an SMTP client as well, when SOAP over email is needed?

I'm willing to bet this has something with the JSR, SOAP planned as the way to get PHP and Java to interoperate.

Would be interesting to hear the story behind it.

Edit:


Just found an article on it, published this week: http://www.zend.com/php5/articles/php5-SOAP.php

[NativeMind]

That's a good point Harry, SOAP can be sent over any transport, so hopefully the extension will address that at some point.

The good news is that PEAR SOAP and the C extension in php5 have a very similar API so it won't require too much extra work to switch between them.

[lastcraft]

Hi...

I just wanted to get some opinions on people who have used one of the PHP SOAP packages.

Is this an internal service or a published one?

We have a deployed web service right now. I can tell you straight away that you will get a wave of support requests in a variety of different programming languages. Are you ready for this? This week alone I have personally had to handle one Java, one Perl and one VB. I have also just added an (outsourced) C# tutorial.

The only way to debug these is to get people to send the raw XML packets. You will have to be fluent in the SOAP envelopes and X-Schema to debug SOAP .

I am so glad that we opted for XML-RPC rather than SOAP. It's bad enough getting Apache to talk to M$ stuff without having to cope with the appallingly documented PHP stuff. Using PHP as a client is fine, setting up a server is a real nightmare (you got further than me ). Also the libraries (not just PHP) seem to insist on generating the WSDL from the code. This has got to be seriously daft . WSDL already defines the interface completely and so is already the ideal source file. It would make the whole business easier to use as well.

We use the incutio library which is small and easy to use because the marshalling is hidden. Expect to have to fix bugs in it though. So far we have found it losing type information (since fixed by the author) and failing to properly encode struct keys. We had to hack the code ourselves.

Another problem is pure PHP though. Because arrays and hashes are the same in PHP (one of the biggest PHP mis-features IMO), incutio has to guess the type from the array keys. The snag is empty hashes look like empty arrays. You can be returning structs all day and then suddenly an empty hash sends out an XML-RPC array instead. Really confuses strictly typed clients (Java, C#).

I am not sure PHP is yet completely able to do web services. Anyway, keep us informed .

yours, Marcus

[Widow Maker]

You will have to be fluent in the SOAP envelopes and X-Schema to debug SOAP

[NativeMind]

Hi...
Is this an internal service or a published one?

We have a deployed web service right now. I can tell you straight away that you will get a wave of support requests in a variety of different programming languages. Are you ready for this? This week alone I have personally had to handle one Java, one Perl and one VB. I have also just added an (outsourced) C# tutorial.

The only way to debug these is to get people to send the raw XML packets. You will have to be fluent in the SOAP envelopes and X-Schema to debug SOAP .

Another problem is pure PHP though. Because arrays and hashes are the same in PHP (one of the biggest PHP mis-features IMO), incutio has to guess the type from the array keys. The snag is empty hashes look like empty arrays. You can be returning structs all day and then suddenly an empty hash sends out an XML-RPC array instead. Really confuses strictly typed clients (Java, C#).

Well at work it's an internal embedded interface to be used in our communication appliance. We currently have a mix of PHP and Java SOAP interfaces (The Java being Apache Axis). For at least PEAR SOAP and Axis, they both have a mapping of the SOAP standards types to internal data types. The point of agreement is on the standard, and not necessarily at the programming language level.

I would say you have to know more XML in XML-RPC since the definitions are so loose. With SOAP the basic data types are standardized and the description of complex data types are also standardized in the WSDL.

Were your support requests oriented around the developer not knowing the intricites of their programming language? I.e. how a SOAP integer is represented in their language? Or was it a lack of understanding of SOAP?

By the way, people say SOAP is complicated but I think once you start looking at it, it's quite easy. The development tools (like BEA Weblogic) are one of the strongest selling points.

I think once there is a need to do attachments SOAP will be even more important. FYI, Microsoft uses SOAP in their MSN Messenger client (which uses SIP (RFC 3261). They attach SOAP messages to some SIP messages for doing things like updating the buddy list.

[Widow Maker]

BEA WebLogic ??

What for example, would you do if you did not have WebLogic huh ? The point is, not everyone has the benifit of tools like these.

Real developers develop, they don't use poncy tools

[NativeMind]

Well hey, that's the beauty of PEAR... there's very little overhead of taking an existing method and turning it into a SOAP method. The only real SOAP you need is knowledge of how complex types are defined.

I think there are a handful of free soap tools out there anyhow

[HarryF]

Just throwing a link;

Service-Oriented Architecture: Chapter 13: Thirty best practices for integrating Web services, Pt. 1.

Sample of a book. Fairly general but thought provoking.

[NativeMind]

I've been promoting a service oriented architecture at work for a while since our system is very complex with multiple managment and end user interfaces supporting multiple protocols and programming languages. Web services are a great fit for getting things to talk to each other. We also break the ties for having components resident on the same box.