Brief description

Version

To discover the version and other metadata about deployed service code that fulfills this API, please utilize the Service Catalog Service.

Overview and Definitions

The Notification service executes requests to notify individuals and groups in accordance with access permissions and user-expressed communication preferences. The service has two types of usage:

Dissemination of broadcast messages. This functionality is invokable through the service's RESTful API.

Dissemination of messages on a topic to registered subscribers. This functionality is invoked through the service's SOA API, a Java interface.

Notifications are disseminated in all cases as e-mail messages. (Additional messaging modalities may be added to the Notification Service in the future, if and as required.)

Broadcast messages are sent when an authorized client directs a POST request to the service endpoint, as documented below. An XML document in the body of the post determines the content of the message and its recipient(s).

Topical messages are initiated by other services as clients to the Notification Service. The Notification Service disseminates messages (Notifications) to registered subscribers (Notification Consumers). Notifications are aggregated in Topics. A Topic has a lifetime, set on its creation by setting of an expiry date. A Topic may have a lifecycle that includes multiple messages of different types; a message type is described in this API as a Situation.

The general process is as follows:

Create a new topic, providing a topic name and an expiration date

Subscribe one or more notification consumers to the topic and one or more situations for which the consumer is to receive notifications (situations may be any strings the client service chooses; examples might include "start", "complete", "error", etc.)

Initiate message dissemination prior to the topic expiration date, one or more times, by creating a new situation for the topic

Known Issues

There is no method exposed to DELETE a notification consumer from a topic / situation. This functionality may be added in a future release of the Notification Service, if/as required.

ROA Layer API

The RESTful service method exposed for the Notification Service permits a RESTful client to Create a Notification, i.e., to send a message to a specified set of Bamboo Persons and/or supplied e-mail addresess.

Base URLs

It is assumed in this documentation that no centrally-run instances of the Bamboo Services Platform will be running after the project ends on 31 March 2013. Therefore, base URLs are assumed to be on a developer's machine, localhost. The base URL with a port number assumes that the BSP is running unsecured; the URL without a port number assumes that security is enforced and Apache Web Server is intercepting and redirecting service calls. Please see the page Identity and Access Management - Authentication and Authorization for context, as well as links to installation and configuration instructions for secured instances of BSP.

Note that ONLY services at v0.9 or greater will run properly in a secured instance of the BSP.

Client Responsibilities in Requests to Secured BSP Web Services

This section of the Service API documentation describes a client application's responsibilities when making requests to secured Web Services hosted on the Bamboo Services Platform (including this service).

A secured instance of the Bamboo Services Platform (BSP) implies a significant set of installation and configuration tasks for which the operator of the BSP is responsible. These are described in overview on the wiki page Identity and Access Management - Authentication and Authorization, and in detail on pages linked from that one.

(1) A client must be configured as a Trusted Application if requests are to be treated other than as Anonymous

A client application – whether a web app or a simple testing client such as Firefox Poster or curl – may make requests anonymously or as a "Trusted Application." Only a Trusted Application may assert the identity of a user on behalf of whom the request is made, and scoped roles to be assigned to that user; Bamboo Services trust such clients to assert the identity and assigned-roles only of users who have authenticated in the current session of application activity. (A special-case type of client application, termed Innovation Licensed applications, are trusted to assert the identity of and roles assigned to a fixed set of special-case users without those users having to authenticate in the current session.)

X-Bamboo-AppID: A UUID that identifies the client research environment, application, tool, or service; this UUID is issued as part of the process of registering a trusted client in the Bamboo Trust Federation as described in overview on the page Identity and Access Management - Authentication and Authorization; and in detail with respect to physical establishment of trust on the pageConfigure Apache Web Server for Client Auth. The value of this header is linked to the X.509 certificate by which the application establishes an SSL connection to the BSP host in the registration process, and a match between this Application ID and the linked X.509 certificate is checked by the BSP on receipt of every request.

X-Bamboo-BPID: A UUID that identifies the logged-in user on whose behalf the request is being sent; this value, a Bamboo Person Identifier, or BPId, is obtained via a call to the Person Service that occurs in time between user login and any other service request. See the Read a BambooPersonId method of the Person Service API for details. [†]

X-Bamboo-Roles: A pipe-delimited (|) set of scoped roles asserted by the trusted client to belong to the logged-in user, of the form role@domain, which are to be evaluated as factors in the determination of whether the request satisfies policies (access restrictions) that apply to the requested resource. If a user is authenticated, the client is expected to include the role undefined@domain where domain identifies the organization that authenticated the user (example: undefined@google.com is a client app's assertion that the user authenticated to Google). This header is otherwise optional (depending on policies governing the requested resource that may require one or more scoped roles for access to be permitted). Example of multiple roles asserted in this header: roleA@domainOne.xxx|roleB@domainTwo [‡]

[†] The value of X-Bamboo-BPID is set to the identifier for the application itself (X-Bamboo-AppID) when a client application calls the Person Service to create a new Bamboo Person Identifier; or to retrieve the BPId for a user based on the identifier of the IdP with which she has logged in and an SHA-256 hash of that IdP's user identifier for the logged-in person.

Exceptions

If an error occurred, some non-2xx code will be returned. Check the HTTP Status Code that is returned in the response's HTTP headers for the specific error. The following errors may be returned in response to the POST request:

Error (Status Code)

Meaning

Returned When

400

Bad Request

If the broadcast XML content is invalid or missing

401

Unauthorized

The requestor is not authorized to publish notifications because the client submitting the request either has not provided authentication credentials, or authentication failed, or authorization has been refused for those credentials

Subscribe a Notification Consumer to a Topic (passing e-mail address for consumer)

/**
* Subscribes a Notification Consumer to a Topic using the
* provided <code>NotificationChannel</code>.
*
* @param topicId - identifier of the Topic to which to subscribe
* @param emailAddress - <code>NotificationChannel</code> to use when subscribing to the Topic
* @param situation - value which will trigger the notification
* @throws <code>IllegalStateException</code> if the Topic does not exist
*/
void subscriptionRequest(UUID topicId, String emailAddress, String situation);

Create a new Situation for a Topic

/**
* Creates a new Situation for a Topic.
*
* @param topicId - identifier of the Topic
* @param situation - value which triggers notifications; "ALL" will match any situation
* @param message - content which will be disseminated as part of a Notification
* @throws <code>IllegalStateException</code> if the Topic does not exist
*/
void publishSituation(UUID topicId, String situation, String message);