*Attendees*
Lynn McRae, Stanford U. (chair)
Dave Donnelly, Stanford U.
Mike Olive, Stanford U.
Gary Brown, Bristol U.
Tom Barton, U. Chicago
Steve Olshansky, Internet2
Jessica Bibbee, Internet2 (scribe)
Carry Over *Action Items*
[AI] {Lynn} will follow up with {Michael} regarding how much history should be kept, and just how it is kept. (3-Aug-07)
[AI] {Dave Lynn} will add LDAP config samples in the wiki for sources.xml file. (3-Aug-07)
[AI] {Lynn} will share an updated version of use cases for Hooks. (25-May-07)
*Agenda*
1. Identifying Roadmap items created in collaboration with Grouper as an outcome of the I2 Fall meeting.
The primary items are:
- The impending XML package release
- Recent discussions on the Grouper calls concerning Web Services interface to Signet and Grouper services
This was generally a priorities and strategy discussion, including aligning approaches with Grouper development to facilitate the integration of our toolkits into more unified infrastructure.
*Discussion*
-Developer Responsibilities-
{Lynn} announced that he will be handing over the responsibilities of lead developer to {Wendy Jones, Mike Olive, Bruce Vincent, and Scotty Logan} during a transition period over the next three months. While he will not be officially on the developer list, the WG can expect {Lynn} to stay involved in the project.
- Recent discussions on the Grouper calls concerning Web Services interface to Signet and Grouper services-
{Lynn} discussed that Signet is actively working on import/export capabilities, which will help to control better programmatic access to managing metadata, in a consistent way with XML import/export. It would also serve as a pathway to web services.
{Tom} mentioned that Grouper does have import/export capabilities, though it was not designed with the extent of capabilities that are now needed.
The Group discussed the emphasis on and priorities for web services. {Gary} said he was most familiar with the soap model; {Bob Morgan} seemed to be advocating a REST approach. Some will want a fully exposed UI so that they can write their own UI, while the aim of others is simple group generation. {Gary} continued, saying that it is likely they will have to support both types of models as many are approaching web services from various angles.
Web services has a lot of interest at the moment, and the WG needs to better understand what it means in terms of product build out. {Lynn} said he was currently more sympathetic towards REST; with minimum packaging, has HTTP GET/POST and proves that the product can be packaged as web services. REST is simple and has a high degree of accessibility.
Candidate tools should be compared first with requirements. Which capabilities are most important to folks? How much consideration should the WG devote to specific soap implementation or to consuming web services? {Tom} mentioned that {Chris Hyzer} is working on summarizing recent discussion around minimizing labor, applying a pragmatic filter, etc. As the WGs gather more substantial operational requirements, there will be a strong need for tools to help deal with those issues. {Steve Langella} has knowledge that would benefit this work, stemming from his experience with NIH on the caGRID project including a new UI with a web services behind it < http://www.cagrid.org/mwiki/index.php?title=GridGrouper:Main >.
{Lynn} discussed various levels, i.e., how fine-grained the capabilities are: a straightforward object exchange or, e.g., one may be interested in just pruning a tree, reconciling documents, or rolling back due to a policy change. {Tom} confirmed that there is substantial interest in this layer, with not only a group information service, but a group management service to expose. The Group discussed whether certain transactions should be handcrafted or whether tools could be leveraged, for greater visibility into management operations (update, create new, etc.) as they see fit within a group management context.
{Gary} suggested starting with the more straight-forward approach of SOAP, and allow the REST approach to develop over time. An adaptation of the approach would be to create/define XML object to convey the bulk of the capabilities under the API. While the initial capability (path) would not meet all needs, it would provide transactional/operational capabilities.
{Lynn} extracted 2 points from the discussion: 1) is there a style of interaction that avoids XML (and would that be a bad approach?) and 2) if XML was used for everything, how SOAP accommodates this? {Gary} noted that some tools ( e.g., Apache Access 2.0) incorporate some level of support for REST.
Other capabilities include point management capabilities and a need for those managing to exercise as a utility, e.g., make it locally scriptable without the overhead of doing a remote implementation.
-Roadmap, Future-
{Lynn} wants to frame the next steps of Signet work around the primary needs of those planning to use it everyday: business rules, program hooks, web services. Web services will be a top priority for Grouper, alongside a continuation of the Hooks discussion. Efforts will operate in series, with implementations working in parallel. {Tom} also expressed interest in more thoroughly integrating groups with Signet.
{Lynn} will notify the WG list with an updated Signet Roadmap [0] with emphasis on integration and web services, including prioritization of items within Signet, alongside that of Grouper.
The next Signet Working Group call is scheduled for Friday, December 21, 2007 at 11am EST.
********************************
[0] Cf. email from {Lynn McRae}, 7-Dec-07, subject: Signet call, combined Signet-Grouper roadmap.
Folks,
I alluded in the agenda to the collaborative Grouper/Signet roadmap. If you haven't seen it, the Signet version is at:
< https://wiki.internet2.edu/confluence/display/SignetWG/Priorities+for+Functional+Enhancements >
It closely follows the original found on the Grouper site, with Signet specific augmentation.
Some form of Web Services support has emerged as a desired focus, at least in the Grouper discussions, which likely reflects a real need to close the loop on supporting an integration strategy.
I think we have a good XML strategy leading there, but will need to reflect this in the roadmap, and balance this new priority against the older ones.
Lynn