Grouper Web Services

To get a list of groups that A is a member of, call getGroups, there is a soap example there. Note: just use g:gsa as the subject source, and the group name as the subjectIdentifier, or the group uuid as the subjectId. You can change the query to ask about immediate, effective, nonimmediate, etc. I think you can get similar information from getMemberships (using the same subject call as described above)

No, you should use the version of Grouper bundled in the web services.  This makes it a little complicated if you have a UI / GSH / etc running against your Grouper DB.  You will need to keep them in sync...

SOAP is supported since many schools required it.  REST-Lite is supported because many schools required it.  XML-HTTP is supported because Axis2 gives it for free when building a SOAP web service.  This way the same SOAP interface can be accessed by clients who only want to talk HTTP and XML and not SOAP.

The URL for ramprt or not is the same.  Inside the services.xml in the .aar files, it configures the app name.  grouper-ws will not work if you change this (unless to do other build activities also)

The non-simple operations are batchable if the client wants to do one operation multiple times with one request.  The simple operations are for if the client only needs to do one thing (e.g. assign a member to a group and not assign multiple members to a group).  Also, there is a valuable side effect that for the XML-HTTP, if the operation only has scaler input params (and not complex types or arrays), that the input does not need XML, it can be in the query string for GET or in the http form param pairs in the body for POST.

It is confusing that there are so many different ways to call grouper via web service.  The documentation will be improved to make it easier to find the best strategy.

This is an unfortunate "feature" by axis, the default element is named "return" which is a keyword in many programming languages, so if the language automatically converts the xml to an object graph, then it will be broken.  Chris will followup with Axis to see if there is a fix for this

For two of three of the flavors of web services SOAP faults are not an option since they are not SOAP.  Also, for SOAP batched, the status of each line item needs to be returned for the client to process, and a SOAP fault would preclude that.  Also, the fewer SOAP specific features that are used, the more widespread the compatibility will be.  All three flavors of web service use the same underlying logic, so the more consistent the better.

Yes, this will be added