Scribing Template --Tues., Nov 12, 2013 at 10:45am -- Monterey Room

TOPIC:  Message Based Provisioning

CONVENER: Michael Gettes, Nick Roy

SCRIBE: Nils

# of ATTENDEES: ~20

MAIN ISSUES DISCUSSED:

Provisioning for identity related activities

How to deliver to external/intern Applications

Various exisiting Strategies discussed

 See photos atached for schematic

Dispatcher to work on the cue. Hardcoded or Rulesbased? Handle CRUD operations, where R is probably Reconcile

What do we need?

- Message Formatting

- Dispatcher?

- APIs

- A change must be atomic

Brown has a prototype service

Vendor independent: Activity Streams: JSON based

Challenge: Feedback loop. How to get a acc from the remote system

If say grouper is both sending and receiving messages, how to prevent cascading

Question:

Put the actual data in the message, or just the pointer to the message

Always include state test to prevent need for too much checking

Who are the actors?

- Who produce messages?

- Who consumes them?

-> Standardize connectors? Code vs Config?

* 'Grab and Fork'

* Simple programming language needed (PERL?)

* Must have simple message format

Create manifesto to state general direction?

Last mile problem is the problem for the consumer.

Messaging will probably not fix your data management problem.

Dispatcher:

* The Dispatched sees all Queues and can distribute messages from 1 queue to the other(s).

* The Dispatches is a router, preferably not intelligently operating on the content of the message, that is a job for there receiving party

* Dispatches can be multiple.

* Dispatcher can be workflow based or target based (e.g. handle LDAP changes).

Consistency

* Long running jobs can create problems with consistency and reconciliations

ACTIVITIES GOING FORWARD / NEXT STEPS: Interested collaborating parties should stay connected and collaborate: CMU, Penn, PSU, Iowa, Tulsa, U. South Florida, Duke

If slides are used in the session, please ask presenters to convert their slides to PDF and email them to acamp-info@incommon.org

  • No labels