JpaNotificationService - Push-Model Notifications

Owned by Andrew Wills (Deactivated)
Last updated: Feb 17, 2015 by James Wennmacher (Deactivated)

This Page

This page describes a proposal for a new, concrete implementation of INotificationService based on Hibernate & JPA.

Purpose of the JpaNotificationService

The existing implementations of INotificationService are all based on a pull model – they reach out to sources of notifications when a user accesses the portal and pull them into the portlet for display.  Pulling notifications works well in many scenarios (e.g. syndicating an RSS feed as notifications), but in not ideal for every circumstance.

For example:

  1. Some adopters may want to emit notifications from processes/services (such as periodic batch jobs) that don't readily provide a persistent endpoint to pull from
  2. Some adopters may want to support user actions on notifications (such as dismiss, favorite, or mark-as-done) that would require significant enhancements and coordination between the source system and the Notification portlet within a pull model

Point #2, moreover, would require one-off enhancement in every source system that wants to support these behaviors;  baking them into a push model notification services allows every service to use a common implementation.

Implementation Overview

The proposed architecture for the JpaNotificationService is based on Hibernate and JPA managed by Spring.  It follows the same principals and practices in common use with uPortal and Apereo portlets such as Calendar, News Reader, and Announcements.

Other Examples

The three portlets listed here as examples – Calendar, News Reader, and Announcements – were developed in different eras. They don't all do things the same way, and perhaps none of them do things exactly as we would do them if we wrote them today. The Jpa/Hibernate implementations in these portlets convey the spirit of these practices and represent milestones on the evolutionary path of these practices in uPortal/Apereo portlet development.

Notes on Data Model

Notes:

  • Adressee and Recipient are optional.  They are useful when you create an Entry that is for a group and you want to record a snapshot-in-time of who the members are of the group.  They are available effectively for auditing purposes.  Once you get all the Recipients you could then view the Event information as sent to a specific recipient.
  • There are 0 to n Event records for a particular Entry.  They record a history of the states an Entry was in for a particular user.  However some activities can remove a particular state (unread to read for example).

Sample Notifications SQL

For the present, you can use the following SQL to make a notification available in the JpaNotificationService for testing.  Down the road, there will be a REST service to create them and (possibly) an authoring interface.

Create a notification for the admin user on HSQL
INSERT INTO "PUBLIC"."NOTICE_ENTRY" (ID,BODY,CATEGORY,DUE_DATE,IMAGE,LINK_TEXT,PRIORITY,SOURCE,TITLE,URL)
VALUES (1 /*not nullable*/,'<p>Hello World!</p>','JPA',null,null,null,5,'JPA','First JpaNotificationService Alert' /*not nullable*/,null);


INSERT INTO "PUBLIC"."NOTICE_ADDRESSEE" (ID,ENTRY_ID,NAME,TYPE)
VALUES (1 /*not nullable*/,1 /*not nullable*/,'Amy Administrator' /*not nullable*/,0 /*not nullable*/);


INSERT INTO "PUBLIC"."NOTICE_RECIPIENT" (ID,ADDRESSEE_ID,USERNAME)
VALUES (1 /*not nullable*/,1 /*not nullable*/,'admin' /*not nullable*/);


INSERT INTO "PUBLIC"."NOTICE_EVENT" (ID,STATE,TIMESTAMP,USERNAME,ENTRY_ID)
VALUES (1 /*not nullable*/,0 /*not nullable*/,{ts '2015-01-19 09:49:45.863000000'},'admin' /*not nullable*/,1);