Amon Horne, Adam Lister, Steve Landry, Mike Moretti, Seth Seligman, and Dave Tanner in attendance.

We began the discussion of the requirements for the Messaging and ESB services that the Working Group has requested ISDA explore. The following are from Steve's notes.

Core Concepts

  • Service mapping
  • Application authentication
  • Applications pushing notifications to humans
  • Messages as document workflow
  • Notification audit trail

Service Mapping

  1. SAIS should be able to build web services against MITSIS or SAP deployed to their own application server environments since sometimes their environments have particular connector or security configurations that need not be duplicated on the ISDA web-services environment. ISDA should then forward to those services.
  2. DLCs should be allowed to map their services from their systems so they can share data with each other.

Application Authentication

  1. Web services security based on x.509 certs and user identities is top heavy, a barrier to entry for DLC developers who want to integrate. We should explore linking the relationship of application identities to touchstone so the web services can authenticate the application-user and the human user through the same mechanisms.

Applications Pushing Notifications to Humans

  1. There is a huge economy of scale in merely presenting a notification service for applications so that localized emailer code is not necessary. Complexities cited given mailman/moira duplication, etc. No one thinks it's easy.
  2. A "message" need not be forced to be email. ISDA could present user preferences to allow end users to choose how they would want to be notified (Overhead, later version?). Steve cites that a push-to-chat could solve another ISDA problem -- Zephyr.
  3. DCAD is working on a project where the customer would want notifications to be given a priority, therefore the end user would have different options for messages of different priority.

Messages As Document Workflow

  1. The best way to tell this one is with a story from the events-registration design
    • An events registration system takes a registered events and submits it to a workflow queue as a possible "mit event."
    • The information center, through the events-calendar administrative UI, accesses that queue and decides which of those documents qualifies as a publishable event.
    • The "event documents" they select are imported into the events calendar, where the business admins can also add additional information that the system of record did not possess.

Audit Trail

Some of the group felt that there is some liability that is not covered by all the localized notification systems. 

  • No labels