Groups API Questions - Structure

Owned by Chris Hyzer
Last updated: Jan 11, 2011 by EricEVersion comment
2 min read

Questions

  1. Simple API (like OpenSymphony), or complex
  2. More operations that are well defined (KIM), or fewer operations with options (Grouper)?
  3. Should we separate out the consumption vs the management of groups (i.e. read groups from subject vs add subject to group)
  4. Should we provide a client (Java, command line, other?)

COmanage responses

  1. The needs of COmanage Gears are pretty simple: basically add/query/delete groups and their members. Requirements of domesticated applications will vary.
  2. No preferece.
  3. COmanage Gears would prefer that consumption and management be handled via the same mechanism. Requirements of domesticated applications will vary, but many will consume group data via LDAP or a provisioning mechanism.
  4. A PHP client would be needed (and COmanage could help write it).

Grouper responses

  1. OpenSymphony is too simple, probably need more functionality
  2. Fewer operations with options is more scalable as we add more options later (dont have to redefine a suite of operations).  It has worked well in Grouper like this
  3. Grouper handles all operations in the same service which works fine
  4. The Grouper client has been very useful, so we should provide one

Kuali responses

  1. Depending on how you interpret the term "simple", the api needs in Kuali for groups is fairly simple (though there are a lot of fine-grained operations on our GroupService).  But we basically just need a way to query group information, check membership, modify membership, etc.
  2. I assume this means instead of having lots of fine-grained service methods, have fewer methods with parameters that define their behavior.  KIM does the former primarily but if having fewer methods with options makes for a better api then I don't think we would be against it.
  3. KIM separates these two out (we have a GroupService and GroupUpdateService defined).  The original rationale there was that the ratio of clients that would need to perform pure query operations vs. those that would need to update this data via the API was heavily loaded toward those who were just consuming the data.  Keeping them separate allowed for a little bit easier task when securing the services then if they were part of the same service.  Though I don't believe we are wedded to that approach assuming whatever we put together considers any appropriate security concerns.
  4. A client is obviously a useful thing, but in order to provide a client we need to provide one using a particular technology which seems to me to be outside of the scope of defining an API for groups.  So I would envision that as possibly a separate project (or set of projects).

NAU Responses

  1. Prefer rich functionality like Grouper Client, but with simplified interface.
  2. Fewer operations with options seems more flexible and easier to enhance.
  3. No.
  4. A java clint would be very useful. We like the way Grouper Client handles the web service call details. If the preparation for a call and handling of results and error information could be simplified, that would be ideal.

Etc