Grouper Developers Forum

["GW Brown, Information Systems and Computing" <>]

Chris,

Some responses to your 'issues' below, but first some semantics...

My understanding of the REST approach is that it advocates using PUT, GET, 
POST and DELETE for Create, Retrieve, Update and Delete (CRUD). addMember 
essentially creates one or more Memberships and so would probably be 
considered a PUT - which would presumably take some actual XML as input? 
Subsequently, I would expect a response of XML which would give an overall 
status for the operation, and, perhaps, individual responses for each 
subject if there were an error, and possibly the uuids of the resulting 
objects - or the objects themselves coded in XML?

I'm not sure that the Group lookup is quite right. I would expect the 
lookup to happen in a separate call so that the client then has a specific 
Group uuid or name to pass to addMember. extensions should be unique within 
a stem but not between different stems so the lookups could retrieve > 1 
Group. Stems can be nested to any level. You have 
&groupStemExtensions=stem1:stem2 which I would take as stem2 being a child 
of stem1 whereas wsGroupLookup.setStemExtensions(new String[]{"stem1", 
"stem2", "stem3"}); implies separate stems in which you lookup the 'query' 
extension?


> Issues
>
> 1. How should error handling work.  Im keeping it in the body itself, but
> should we use SoapExceptions?  Not sure how that affects REST, but we
> could try.  Also, an advantage of not doing this is we can delimit the
> string so there can be a friendly message
As indicated above, for REST I would expect an XML response rather than 
something SOAP specific.
> 2. GroupLookup: - is there a way to lookup a group by all stem extensions?
There is a Group query system based on GrouperQuery which uses QueryFilters 
to construct complex queries. GroupFinder has a findByAttribute method 
which could search on extension - but is likely to do a case-insensitive 
substring search. I think we need to discuss Group lookup on the call
> 3. StemLookup: - is there a way to lookup a stem by all stem extensions?
As for 2
> 4. Stem names: - can a stem extension contain a colon?  Anything it cant
> contain?
They can't contain :. I don't think the API imposes any other restrictions, 
though the UI does (they should probably be removed. I would advocate not 
using < > and & given implications for XML escaping though & may be hard to 
avoid
> Extensions should never change, right?
Actually the API does allow it. If you change a Stem extension all 
descendant stems and groups have their names changed - which could take 
quite a long time in some cases. In fact, I've found in loader scripts that 
you need to be really careful not to use setExtension or 
setDisplayExtension on Stems unless you are really changing the value!
> 5. Where to specify the max in batch? (which config file)
If a batch method is added to the API I would suggest grouper.properties. 
It raises the question of whether there ought to be an appropriate 'query 
method so clients can determine the maximum allowed
> 6. Subject search: - id vs identifier?  which to use?
Probably ought to allow either. In addition to:
 subjectLookups[0].setSubjectId("abc");
have
 subjectLookups[0].setSubjectIdentifier("xyz");
They could be mutually exclusive i.e throw an exception if the other has 
been called, or use id in preference if both set.
> 7. Transactions: - how should they work, or should a param specify?  i.e.
> if any fail should all fail, or just the one that failed?
Probably have a param specify. Currently the API is likely to throw an 
Exception if the Subject is already an immediate member of a group. We may 
not want a batch to fail because of that.

Gary

--On 09 January 2008 03:30 -0500 Chris Hyzer 
<>
 wrote:

> To Sanjay, looks like good progress, and will make for interesting and
> helpful discussion.  Thanks!
>
> To everyone, I have been working on the web services that will live
> inside of Grouper in the next release, and here is my progress on the two
> AddMember operations:
>
> https://wiki.internet2.edu/confluence/display/GrouperWG/Add+Member
>
> Kind regards,
> Chris
>
> > -----Original Message-----
> > From: Sanjay Vivek 
> > [mailto:]
> > Sent: Tuesday, January 08, 2008 11:33 AM
> > To: Grouper Dev
> > Subject: [grouper-dev] Updates on Grouper and WS.
> >
> > Hi everyone,
> >
> > This is a brief progress report on our work with Grouper and WS. We
> > currently have the following Web Service Calls:
> >
> > 1) getGroupMembers(String groupName) - returns all the members of a
> > group
> >
> > 2) getMemberGroups(String userID) - returns all groups a user is member
> > of
> >
> > 3) addUserToGroup(String userId, String groupName) - adds user to a
> > group
> >
> > 4) deleteUserFromGroup(String userId, String groupName) - deletes user
> > from a group
> >
> > We have so far successfully tested the WS with both Java and PHP
> > clients. We are looking into further testing with .NET and Ruby.
> >
> > We are currently working on Web Services authentication using Apache
> > Rampart. One of the things we're looking at is identifying the user
> > once
> > he has logged in and using his credentials to figure out whether he is
> > authorised to add user to a group (as an example).
> >
> > WS authentication was slightly easier with Axis1 because Axis1 could
> > easily be set up for HTTP authentication (since Axis is implemented as
> > a
> > servlet in a web app). However, things are different with Axis2.
> > WS-Security is the preferred method of authentication for Axis2.
> > Rampart
> > wraps the WSS4J functionality (the library that implements WS-
> > Security),
> > and can be integrated into Axis with little effort.
> >
> > A detailed reference to authenticating Grouper WS with Rampart will be
> > posted soon. Cheers.
> >
> > Regards
> > --------------
> > Sanjay Vivek
> > Web Analyst
> > Middleware Team
> > ISS
> > University of Newcastle Upon Tyne



----------------------
GW Brown, Information Systems and Computing