Signet Call 09-May-2008

**Signet Call, 09-May-2008**

**Attending**

Mike Olive, Stanford (chair)
Dave Donnelly, Stanford
Chris Hyzer, U. Penn
Josh Drummond, UC-Irvine
Neil Matatall, UC-Irvine
Michael Gettes, MIT
Steve Olshansky, Internet2
Emily Eisbruch, Internet2 (scribe)

*New Action Items*

[AI] (MikeO) will update the roadmaps to reflect current status, and
work with SteveO to ensure they are prominently linked at the top level
of the Signet wiki.

[AI] Chris will write proposed requirements and usage cases for handling
of notification and plug-ins. These will include possible modifications
to the Hooks & Plug-ins requirements and design documentation, Sections
3.2 and 3.3.

*Carryover Action Items*

[AI] (MikeO) will send a note out to the list with some context about
auditing issues and requesting folks to talk with their respective
auditors for their perspectives, and report/discuss via the list.

[AI] (MikeO) will develop an initial strawman set of test cases to float
to the list for feedback.

[AI] (MikeO) will contact {Michael Gettes} about potential COmanage
requirements to drive Signet functionality.

*Agenda*

Hooks & Plug-ins requirements and design documentation review.
https://wiki.internet2.edu/confluence/pages/viewpage.action?pageId=23183

**Discussion**

MikeO has worked with Tom Barton on the centralized, combined
Grouper/Signet roadmap, now available on the I2MI-Common wiki site.

The schedule for upcoming releases was discussed. Dave stated that he is
wrapping things up on Signet version 1.3, ETA not yet firm. Currently
the group is looking at hooks and plug-ins for Signet version 1.4. Dave
stated that he expects hooks and plug-ins will go fairly quickly, though
this will partially depend on the results of today’s discussion. Writing
plug-ins will be responsibility of independent developers. MikeO stated
that web services would be included in a release after 1.4.

There was discussion of location of roadmaps in the wikis, ensuring that
they are easily findable.

[AI] (MikeO) will update the roadmaps to reflect current status, and
work with SteveO to ensure they are prominently linked at the top level
of the Signet wiki.

Dave introduced discussion of the I2MI Middleware Hooks, Notifications
and Plug-ins Requirements document. The document was started in October
of 2007, and hasn’t changed much since then. It is a rough draft and
open for discussion. Dave also noted that the hooks design diagram is a
very rough draft and open for changes.

Discussion focused on the Section 3 (Formal Requirements) of the
requirements document.
Dave reviewed the focus on business-level events, as outlined in section
3.1 of the requirements document.

Dave noted that in an email on the Grouper-Dev list, Chris had requested
a context field so that a plug-in can be aware of where an event
occurred. Dave stated it is easy to implement a string. Chris prefers an
object model rather than a string.

Dave stated it would be nice to have the ability to supply multiple
contexts, i.e. a list of contexts for a given event. So the listener,
when it registers, can indicate which events and which contexts it is
interested in. This would be a filtering system that could reduce the
complexity of the plug-in: The plug-in would not get called when it
shouldn’t.

Dave reviewed section 3.2, Notifications.

Dave stated the desirability of having plug-ins be able to be both
recipients and generators of events, so that plug-ins are not
necessarily “one way.” A plug-in could create and notify Signet or
Grouper of a new event. There was a question about what would need to be
done to the plug-in architecture to implement this. It was noted that
Grouper has multiple entry points and that it would be necessary to load
plug-in code in multiple places –- wherever the Grouper engine is
invoked –- such as in the Grouper UI, GrouperShell, web services.

Dave stated that a single plug-in could have a list of event types it
knows how to handle. If a plug-in developer wants to do the same thing
for two different event types, they would only need to write one
plug-in. This adds flexibility to the design. Also, there could be
internal plug-ins (such as for debugging or log-in).

Pre and post event notifications (3.2.4) were reviewed. Pre-event
notification gives plug-ins the ability to decide if an event should
occur. Consensus of plug-ins notified about an event request will
determine if the event should go ahead or not. This allows the plug-ins
to have some measure of control over application. A plug-in can always
just return an approval status. Post event notifications have less
control because the event has already occurred.

There was a question on whether 3.2.5 (“The System shall provide the
ability to notify one or more listeners for each event”) has a real use
case. Dave noted that modeling was based on the Swing event listener.
The ability to add multiple listeners for an event is the core of the
Swing event processing system. Having multiple listeners is almost as
easy to implement as having a single listener. It is too constraining to
have a single listener.

Chris raised concerns about section 3.2.6 “The System makes no guarantee
of the order in which multiple listeners, for a specific event, will be
notified.”

Chris suggested that we assume there are these categories of listeners:

- User Defined (people implementing Grouper who deploy it on a server)
- Extension (could be Grouper/Signet team or a contributor/school)
- APIs (that the Grouper or Signet team writes)

Chris stated it would be too chaotic NOT to have the events received in
some sort of order; that not having an order could lead to bugs and
non-reproducible behaviors. Chris suggested that user defined events
should be first in queue to be notified of an event.

Should users have the power to change plug-in handling? Should that
power be part of the infrastructure of plug-ins? A distinction was
identified between plug-ins that Signet or Grouper developers write
(which should always run) versus other plug-ins that users can change.

MikeO mentioned that it sounds like we have a couple of different
utilizations of the hooks concept, and that there are internal
interactions and constraint control requirements that Grouper may have
that need to be taken into account in the development of hooks for
Signet, so as to ensure alignment to the degree possible.

(see https://wiki.internet2.edu/confluence/display/GrouperWG/Hooks+simple)

An issue was identified concerning plug-ins creating new events. For
example, the originator of an event creates a group. But what if new
group information is part of the event? This new group information gets
sent off to the first plug-in. The plug-in says “OK, I want to add two
more groups.” Is that going to fire off more events? The conclusion was
that there should be a requirement to execute events without firing off
any more events.

Dave stated that the architecture diagram is already outdated but that
he will wait for further discussion with Chris prior to updating it.

Chris mentioned that he does not think asynchronous event notification
should exist.

Both Dave and Chris stated that they thought it would be a bad idea to
use AspectJ.

Dave and Chris stated that they would like to continue the discussion of
hooks in upcoming Grouper WG call.

The next Signet Working Group call is scheduled for Friday, May 23, 2008
at 11am EDT.