SOAP Web Services Support

I'm currently handing this for a customer, but some design considerations should be reviewed for the SOAP interface to work.

The problems I'm talking about are:

- services naming convention breaks any deliverable form: currently defined services include dot (.) in the service name. For the soap to work, the name of the service should be a callable function. Removing the . is mandatory to avoid breaking the envelope using a wrapper for the services call.
- SOAP requires the definition of types for control operations, so nodes or any other abstract form, like standard objects (could) break the definition, as nodes may have random module-defined attributes. To fix this, the reply (and arguments) of the services should be changed to arrays pairing "name" => "value" the attributes.

I've fixed the first issue, using a wrapper for the calls. It breaks the envelope as the soap service requested is the wrapper instead of the published service, but I can't resolve the abstract objects issue, because doing that is like not using SOAP at all.

So this feature remains hang untill we could find a solution for that. No support is to be given to this server for now.

The file attached is for testing purposes, and should not be considered as a release, neither as a dev release. Just want to share in case someone want's to manage the issues I've created. The module should be copied to the services/servers directory. It has NUSOAP included in the zip, and the NUSOAP library is loaded using require with the path: "testing/sites/default/modules/services/servers/soap_server/...".. Edit the file to match the right path of your services directory.

- services naming convention breaks any deliverable form: currently defined services include dot (.) in the service name. For the soap to work, the name of the service should be a callable function. Removing the . is mandatory to avoid breaking the envelope using a wrapper for the services call.

I'm not sure this is true. Flickr, for example, has no problem with SOAP method names using dot syntax http://flickr.com/services/api/request.soap.html. The call wrapper you're using is totally acceptable, and I'm doing something similar with the XMLRPC module. Basically, the idea is to route all SOAP method calls to a single PHP callback, like soap_call_wrapper(), which then grabs the original method name and namespace from somewhere (ie, 'node.load') and invokes services_method_call() which slaps on the auth key and sessid if set and routes to the correct PHP callback. It seems like you got this part figured out. There's gotta be a way that you can map pseudo method names like 'node.load' to a php callback in the same way that you are able to with XMLRPC. I'm just not familiar enough with SOAP to give you an answer with out digging in. Remember, you can always subclass nusoap's soap_server if you need to.

- SOAP requires the definition of types for control operations, so nodes or any other abstract form, like standard objects (could) break the definition, as nodes may have random module-defined attributes. To fix this, the reply (and arguments) of the services should be changed to arrays pairing "name" => "value" the attributes.

The solution works? Why is that a problem. There is some work going into totally revamping the Drupal data API, which will help with these kind of issues. Until then, there's nothing wrong with some less than ideal solutions.

NUSOAP library is loaded using require with the path: "testing/sites/default/modules/services/servers/soap_server/...".. Edit the file to match the right path of your services directory.

The Drupal solution for this would be to replace:

with

Please find attached a modified version of the SOAP server that addresses some of the concerns raised above. We successfully tested all stock Services functions (node.*, user.*, system.*, views.getView) with that version. The README.txt file contains an example invocation of node.load.

Modifications are:
- Apply Drupal code standard on the soap_server.module.
- Fix path for nusoap library and current path to the name_space (no more hard-coded paths).
- Fix SOAP action path when registering methods.
- Set appropriate return type for the service method - xsd:Array instead of xsd:struct in the case of returning struct or object. Also cast the returning object to an array. This change was made to allow returning dynamic objects (that don't have a WSDL description) to the SOAP client.

Unfortunately we can't stick the nusoap library into Drupal's CVS. Solutions would be to either tell the developer to install the nusoap library themselves, or use PHP 5's SOAP server.

Although I would love this to be part of the core Services package, I think it would be best as a contributed module. Would you like to create the Drupal project and stick it in the CVS, or shall I?

I can try to finish the part of the php's internal soap support or ask for the nusoap part in the module configuration. I've this already working in the sugarcrm connector.

I'm going to test the module tomorrow, I do want to take a look to the code changes.. Thanks a lot for your help!

Rob, I think the soap_server fits really well in the services package instead of stand alone server (because it gets the services from this module), but if you preffer I can create a single project for soap support, and do some work to keep it integrated with the services module, but not requiring it at all.

Does this make happy everyone?

Hi ilo. What I mean is that although it should definitely use the Services API, it might be best delivered as an outside package, like the rest of the related Services server packages (like AMFPHP, JSON, REST, etc).

http://drupal.org/project/soap_server, maybe? This is a great addition to the tools available for Drupal Services, and I'm really looking forward to seeing more pop up!

I totally agree.. let me create the project and do a dev commit with the php5 soap support to start playing with.

Thanks again, melsawy!

- Set appropriate return type for the service method - xsd:Array instead of xsd:struct in the case of returning struct or object. Also cast the returning object to an array. This change was made to allow returning dynamic objects (that don't have a WSDL description) to the SOAP client.

Actually, I could not get this part working. The returning value of the code is just an array containing a single object: the text string: "Array". No more information is returning. I'm sorry Melsawy.. maybe we have very different versions of nusoap or php..

Due to the fault of api definition, as I described in my initial comment, I'll use array as return value in any case.. maybe this is not the best ending and thus breaking the service definition, but it's going to work.

I just want to apologize.. I forgot about this topic, and never realized that snelson did reply in "December 17".. sorry about letting this too sleepy!

I just tested melsawy and your solution using Drupal 6 and it seems pretty slick. All I had to change to port it to Drupal 6 was soap_server.info. Here's a recommendation for the soap_server_server function to gracefully degrade if NuSOAP isn't installed:

Once this stuff is up on the Drupal CVS, we'll be able to submit patches. ilo, could you give melsawy CVS access to the project?

Both you are granted. I just created the project but commited anything yet.

I'm just merging into the .module all the stuff needed to work with nusoap or builtin's php soap and the configuration pages. I planned to commit once the module is a little more usable with some debug and configuration settings. So please, be patient and I'll a commit with code mature enough to start working.

There will be some caveats we stick have to deal with. I'll write a short list with them.

I suggest you commit what melsawy uploaded (minus NuSOAP), and then we tackle the problems with it through the issue queue and patches. If you're having troubles with that, you can give me CVS access and I'll put it up there.

As you requested I did the first commit with a totally broken version of the module. I would like to NOT create any release untill the module is working (even if it works badly), but the current status is full of flaws and will not be usable at all.

By the way, Rob.. about creating a page for the soap server configuration.. do you agree with using the path (admin/build/services/settings/soap) with a new level of tabbed links (as user profile categories) or do I create a simple config form outside of the services menu path?

The module is in the cvs... grab and stress it!

- (admin/build/services/settings/soap)

I like that, but we'll need to patch Services for a default local task at admin/build/services/settings/general.

Great work on all this guys.

Cheers,
Scott

Moved to http://drupal.org/project/soap_server . Ability for configuration settings for server modules discussion can continue here.

Automatically closed -- issue fixed for two weeks with no activity.