Incorrect WSDL generated

Thanks deviantintegral, it fixes the action names, but the arguments of the actions are missing. The $responses variable is present in the wsdl file, but I haven't verified it.

From my understanding, rayvaughn pretended to make it generic for parameters, but I'm unsure if other SOAP implementations (appart from PHP, that is very lazy) would validate the request. I had problems with Java unmarshalling when passing parameters with undefined params SOAP attribute for messages.

Lets see if this is enough to work, deviantintegral, can you give a try using just the actions fix? Otherwise we will have to go through method arguments and create element entries first, then associate as parameters for the messages.

Unfortunatelly, there is no way to make it work unless we get the WSDL fixed. I have committed the patch at #1 (http://drupal.org/cvs?commit=486676) because I'm unable to get valid method to request a test.

Lest continue fixing this one. Thanks deviantintegral!

Sorry, I meant the patch at #0, obviusly.

In my test system the resource array for the node resource doesn't have any actions. I'm going to try testing for a callback to see if it is a method and try and make the WSDL work that way

I've verified that current patched version returns actions for the system resource (dind't go any deeper than that), using a PHPSoap client and the Netbeans web services utility.

Here is a patch that puts type information into the parameters that is gleaned from the resources.
Methods and Action Methods are supported.
I can retrieve or update a node through Soap UI using the WSDL that is generated in this manner.

I have left the dsm calls in to help in testing, I will remove them before committing if the patch looks good.

Defining types for the response part is going to be much more difficult. Is it necessary?

Thinking about it maybe the response object should default to xsd:struct as this is what services resources are returning. Defining the contents of that struct would require services resources to return more information, an idea mentioned in another thread.

I have committed some code which adds type information to request parameters.
Also response type is set to xsd:struct which may be better for clients as I think that is largely what is returned - this needs careful investigation.

The WSDL allows retrieval and updating of nodes through Soap UI.

Note: Services 3.x-dev has a bug node_resource.inc where the parameter type for nid should be int not nid

rayvaughn, should I ask.. next time you do any commit, could you please attach a patch in the issue queue? there is no easy way to view the changes once it is committed but a very frustrating seek and discover research.

Returning struct is a good approach, the same applies to complex arguments also, but the information must come from the services framework, and unfortunatelly you can't rely that a service will return a value when you don't know if this return value exists. PHP Soap is very lazy on that, but other implementations (and I use to play with java server and clients) will hate the wsdl at all.

OK I can put patches up. I assume you know about cvs.drupal.org - I find it really useful for tracking code changes across revisions.
Here is a link to a diff of the latest update to the module: http://drupalcode.org/viewvc/drupal/contributions/modules/soap_server/so...

I'm not sure that services module will know the schema of the objects it is returning. For example nodes can have all sorts of fields added by modules so their schema is hard to pin down.

I have a solution for this for nodes in a module that I will be contributing soon. Hose XML provides a mapping from node data to XML via a UI configurable profile which provides a defined structure for the returned object. The module generates an xsd schema for the node response which can be included in the WSDL. I am working today on the hook in Soap Server to allow this other module to modify/replace the WSDL. The module will be a services 3.x resource which also defines it's response in the WSDL.

I can see that another option would be to use CCK and core functions to get information about node fields and construct a schema for nodes without using the extra abstraction that Hose provides. This I could be included in Soap Server or as a separate module (e.g. cck_node_resource) and would provide the response detail for systems that require more detail.

As for users, taxonomy, system objects etc. a lot more thought is needed.

I guess this stuff will be easier in D7 because maybe there is a get_entity_schema() or similar function?

For now as far as I can see we set the default return type to xsd:struct or xsd:any of that proves inappropriate.

I have been working on this today and certain things have come to light. We can't use an underscore to replace the dot in method names for soap (currently node_retrieve = node.retrieve) because somebody might make a resource with an underscore in the resource name. I propose using node_do_retrieve in the WSDL instead. I don't think anyone will make a resource called something_do but if they do we can report an error in Watchdog.

Here is a patch for todays work -
I've made it possible for another module to override the wsdl.
The token separating resource from method is now _do_
I've added a function to make the wsdl more readable for the debug function
some tidying up

hehe. Yes, I know how cvs.drupal.org works, and that is exactly why I don't find usefull to guess that first: a commit has been made, second: search for it (go back to project page, and click on CVS messages for the module), third: discover that more than one commit has been made, commits not even related to any issue, foruth: go to every changed file using the version link.

I'd take to oportunity to also point you to the 'Saving changes to your module' section of the 'CVS reference guide for module maintainers': http://drupal.org/documentation/cvs/quickstart#commit

Bugs and features are tracked in your project's issue queue. It is customary in the commit message to reference the node ID of the issue where the bug/feature request was raised, and mention any contributors who helped with the code.

Ok, sometimes there is no issue (for small changes, code costemic changes or harmless changes) if the commit does not touch a single line of working code, or not at least one that would affect module's functionality (say, a coder review fix patch). Assuming you have read that section, now I'd refer you to the project commits page: http://drupal.org/project/cvs/213923 and try to find the differences between your commits, and other's commits.

About the patch, I can see some problems because of module namespace collision, there is an endpoint_load() function declared that might be renamed to soap_server_whatever_endpoint_load() or _soap_server_endpoint_load() (DO not use soap_server_endpoint_load() because this name falls into the expected names for hook-able functions from the enpodint module).
Also, instead of replacing the dot with _do_, I'd go for a custom replacement: soap_{name_with_underscores}, so we make a clear difference that the action has been modified by the soap server module.

Abou the rest of the patch, assuming it works, there is no way to test it currently, I'd say "go ahead!" and we'll discover errors as long as the module is being used, but, remember that you are the maintaner of the 3.x branch, it is up to you the way to go.

Thanks for the reminders about commit etiquette. Can we be relaxed about an issue per code change until we at least have an agreed approach to the module to allow agility in trying out ideas in the dev version? It seems a bit early in the development process to be tracking every change in such detail, but I can try and do so if it's important to you.
I prefer to commit often to CVS in the early stages of a project so that bad ideas end up being documented as well as good ones because it makes it easier to remember why certain decisions were taken. Is that ok?

I guess we are coming from a slightly different perspective to the module - for me it is a completely new project, for you the next version of something you put a lot of work in. Keep those criticisms coming! :-)

I certainly agree that once we reach an alpha then all changes must be backed up by an issue properly referenced in the commit message.

So we use %soap_server_endpoint in the menu path and soap_server_endpoint_load()? Makes sense - good idea.

I'll change the resource{token}method to be resource_soap_method as you have suggested.

hehe, so much loved criticism! ;)

It is not about netiquette, it is about traceable changes. I and don't mean to stop the development just because of going through the whole issue queue process for every little change, I'm just pointing that if you want me to review module changes, make it easy for me. As I said, go ahead, commit, change, do whatever you thing it must be done, but don't expect people to be looking for changes in cvs logs to review.

It does not take too much time to create, update a patch file, and reference the commit to the issue comment near the discussion about it.

Soap token fixed in attached patch.
Debug function updated for improved readability

Menu loader changed as suggested in soap_server.module

22c22
< $items['soap_server/debug_wsdl/%endpoint'] = array(
---
> $items['soap_server/debug_wsdl/%soap_server_endpoint'] = array(
29c29
< $items['soap_server/debug_client/%endpoint/%node'] = array(
---
> $items['soap_server/debug_client/%soap_server_endpoint/%node'] = array(
46c46
< function endpoint_load($endpoint_name) {
---
> function soap_server_endpoint_load($endpoint_name) {

Was there some changes done recently, or was it just a late close? I'm experiencing return type problems when communicating with a .Net client. :-/ It seems to insist on string when I return an object.

@fuzzy76 I have the same problem and it still exists in -dev. the issue is with WSDL class generators like wsdl.exe. see #1683024: .net clients think responses are strings