Navigation:
Documentation
Archive



Page Tree:

Child pages
  • Notification Service Description and Assumptions - v0.9-alpha

This wiki space contains archival documentation of Project Bamboo, April 2008 - March 2013.

Skip to end of metadata
Go to start of metadata


Description

Summary Description

The Notification service executes requests to notify individuals and groups in accordance with access permissions and user-expressed communication preferences.

Full Description

The Notification Service's primary function is to disseminate Notifications on behalf of Publishers to those Notification Consumers for which Subscriptions have been registered, against specific Topics. While the Notification Service will be designed to provide a general publish / subscribe capability, the requirements specifically call for the ability to:

  1. Provide a user/client with a notification that their asynchronous request has been processed
  2. Enable a Bamboo Person to broadcast a message to other Bamboo Persons and/or Bamboo Groups

Key Concepts

Topic

A Topic is some subject of interest to NotificationConsumers that is dependent on the Situation. A typical usage pattern is to define a single Notification for each kind of Situation, containing information pertinent to that kind of Situation; typical Topics include:

  • Successful completion of an asynchronous process
  • unsuccessful completion of an asynchronous process

Situation

A Situation is some occurrence known to a Publisher and of potential interest to Notification Consumers. A typical Situation would be the completion of an asynchronous process.

Notification

A Notification is an artifact of a Situation containing information about that Situation that some Publisher (e.g. a Functional Service) wishes to communicate to Notification Consumers.

Publisher

A Publisher is a client of the Notification Service that publishes a Situation for a previously registered Topic.

Notification Consumer

A Notification Consumer is the recipient of a Notification. The Notification Consumer receives a Notification if they have previously subscribed to a Topic. For BSP Phase I, Notification Consumers are usually Bamboo Persons or Bamboo Groups but can also be anonymous users who specify their own Notification Channel.

Subscription

A Subscription is made on behalf of a Notification Consumer by a Subscriber. A Subscription represents the relationship between a given Notification Consumer and a specific Topic.

Subscriber

A Subscriber is any client of the Notification Service that sends the subscription request message. The effect of the subscription request is to add a Subscription to a Topic. Note that a Subscriber may be a different entity from the Notification Consumer for which Notifications are actually produced. For example, this is the case when a Functional Service is acting as a Subscriber on behalf of the Bamboo Person who will eventually receive a Notification that their asynchronous process has completed

Notification Channel

A Notification Channel represents the means by which the Notification Service will send a Notification to a Notification Consumer. A Notification Consumer's Notification Channel(s) are either taken from their Bamboo Person data or can be specified by the Subscriber during subscription.

Assumptions

  1. The Notification Service cannot guarantee that a Notification will actually be received by a Notification Consumer
  2. The only Notification Channel supported in BSP 1.0 will be email
  3. A Functional Service (i.e.g Scholarly Service) will perform the role of a Publisher:
    1. Calls the Notification Service to create Topics
    2. Calls the Notification Service to publish Situations against a Topic
  4. A Functional Service (i.e.g Scholarly Service) will perform the role of a Subscriber:
    1. Calls the Notification Service to create Subscriptions
    2. In order to support the requirements use cases, the Subscriber must support the creation of a Subscription by either obtaining a Notification Channel from the Notification Consumer or by accepting an email address from its client as an override

Overview

The following Sequence diagram illustrates the interactions involved in the general case for providing a user/client with a notification that their asyncronous request has been processed.

  1.  A Functional Service Client makes a request that the Functional Service knows will be long running
  2. The Functional Service, performing the role of Publisher, registers a Topic with the Notification Service
  3. The Functional Service, performing the role of Subscriber, requests that a Notification Consumer be notified when the Situation of the Topic is equal to "Success"
  4. The Functional Service, performing the role of Subscriber, requests that a Notification Consumer be notified when the Situation of the Topic is equal to "Failure"
  5. The Functional Service returns 200 "OK" to the Client
  6. Asynchronous processing over time occurs
  7. The Functional Service, performing the role of Publisher, publishes a "Success" Situation to the Notification Service
  8. The Notification Service create a Notification, which contains all pertinent information referring to the Topic's Situation

NotificationServiceGeneralCaseSequenceDiagram

Dependencies

Result Set Cache Service

While it is expected that a Publisher (e.g. a Functional Service) will likely include a link to content in the Result Set Cache, this behavior is not included in the description, use cases, or models for the Notification Service since said interaction is solely at the discretion of the Publisher and does not require any special processing or capabilities on the part of the Notification Service.

Background Documentation

n/a