Child pages
  • ESB to Grouper Design

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

Previous thoughts on this have been moved. This page represents my current proposal.

The proposal is to go ahead with a lightweight means of communicating events from an ESB to Grouper. The functionality will initially be limited to tasks which satisfy the requirements of implementation at Cardiff University:

  • Add a subject as a member of a group
  • Remove a subject as a member of a group
  • Add a group as a member of a group
  • Create a group

There will be 2 ways of sending a message to Grouper:

  1. Through XMPP - the Grouper Daemon will connect to an XMPP server using the Smack client libraries and filter messages to a specific address, or matching a given pattern, these messages will contain commands formatted as JSON strings
  2. Through HTTP (since we won't be using the XMPP at Cardiff) - Jetty will be started by the Grouper Daemon to listen on a socket and run a simple servlet accepting commands formatted as JSON strings

Both routes of sending commands to Grouper will result in common code performing the task through the API.

I'm currently prototyping this and need to work out:

  • the best way to manage things cleanly from a threading point of view within GrouperLoader. A simple way of doing it would be to schedule quartz to initialise new threads shortly after startup
  • whether a "send and forget" mechanism is sufficient, or whether some feedback to the caller would be better (difficult with XMPP as it's asynchronous)
  • whether I need to worry about security (tentatively: not in a first version, but need to consider it so it can be added)