[aerogear-dev] [AG Push] BASIC (and INITAL) use cases of the Unified Push Server

[Matthias Wessendorf]

Hi,

after two weeks of prototyping and evaluating, I started the design phase
of the AG Unified Push Server.

I created a GIST [1] that defines the INITIAL (not final) first DRAFT of
the supported use cases. Yes, they are very minimal :), but once we have
something running, we can add more features. Please review and comment
here...

(COPY AND PAST FROM GIST):

AG Unified Push - Use Cases

Right now there are the following roles:

   - *Developer*: Some one that setup up the backend for different mobile
   applications, to enable push (e.g. iOS certs or Google API keys(more later)
   - *User*: Install an AG-App on his phone
   - *Admin* needed? yes, once we have a *management user interface*. NOT
   part of the first iteration....

<https://gist.github.com/matzew/7475652fa3b0cbb11c1c#use-cases>Use Cases

Below are the BASIC use-cases, that the AG Unified Push needs to *initially*
 support.

   - Enroll AeroGear-Push-User (based on identified roles)
   - Remove AeroGear-Push-User
   - Developer can register mobile App (for different Push Networks, e.g.
   Apple, Android)
   - Developer can unregister mobile App (for different Push Networks, e.g.
   Apple, Android)
   - User registers his phone with the backend (Device Token + APP-ID are
   send to the backend)
   - User unregisters his phone with the backend (e.g. app got deinstalled,
   user deleted etc)
   - User receives Push Messages (handled by the native OS, once accepted
   to receive messages)
   - Send push messages, done by a *user* or a *developer*

<https://gist.github.com/matzew/7475652fa3b0cbb11c1c#enroll>Enroll

Register different user types (based on desired role) with the
AG-Unified-Push server. The *Developer* role always requires a
username/password. The *User* is not always required on the server. Some
mobile apps don't know the concept of a logged in user (e.g. Sport
Broadcast apps), but others do require a *User* before using the mobile app
(e.g. Twitter)
<https://gist.github.com/matzew/7475652fa3b0cbb11c1c#remove-registered-user>Remove
registered User

It should be possible to remove Users (app users). That can me their
account is erased or their device tokes are removed....
<https://gist.github.com/matzew/7475652fa3b0cbb11c1c#add-mobile-app>Add
mobile app

A registered *Developer* can register multiple Apps with the AeroGear Push
Server. Each app has a (generated) AeroGear-Application-Key, besides that,
the logical concept of a APP, on the server, requires access to the Push
Networks (Google or Apple). Therefore such a registered APP needs a
certificate and passphrase (iOS) or a Google API key (Android)
<https://gist.github.com/matzew/7475652fa3b0cbb11c1c#remove-mobile-app>Remove
mobile app

A registered *Developer* should be able to remove the apps from the server.
<https://gist.github.com/matzew/7475652fa3b0cbb11c1c#device-registration>Device
Registration

Once a *User* installs and launches the mobile app, the embedding OS
generates a *Device-Token* (or *Registration ID* on Android). The mobile
Application needs to send this Token/ID and the AeroGear-Application-Key to
the AeroGear Server, so that the server can register this phone/app with
the particular app, to be able to receive push messages.

*Note: On iOS the user as to agree to receive push messages*
<https://gist.github.com/matzew/7475652fa3b0cbb11c1c#remove-registered-device>Remove
registered Device

If an app gets uninstalled, the phone is no longer able to receive push
messages. Therefore inactive Device-Tokens/Registration-IDs should be
removed, on the server. However... there is no harm if invalid keys are
used, on the server, when trying to send push messages...
<https://gist.github.com/matzew/7475652fa3b0cbb11c1c#receives-push-messages>Receives
Push Messages

Every installed app, is able to receive Push Messages through the APIs,
offered by the platforms (iOS, Android). Initially there will be NO client
SDK.

*Note: On iOS the user as to agree to receive push messages*
<https://gist.github.com/matzew/7475652fa3b0cbb11c1c#send-push-messages>Send
push messages<https://gist.github.com/matzew/7475652fa3b0cbb11c1c#broadcast>
Broadcast

The Unified Push server acts as a broker to deliver messages (via Native
Push) to several devices. Authorized Users (based on their roles) can send
push messages to a specific application. For instance a *Developer* that *
ONLY* owns "AeroGear-App1" is only able to broadcast messages to that
particular app. He is *NOT* able to send a message to "AeroGear-App2"...
<https://gist.github.com/matzew/7475652fa3b0cbb11c1c#filtered-messaging>Filtered
messaging

Sending message to a specific user.... We need a DSL to filter users
etc.... This will be done later...
<https://gist.github.com/matzew/7475652fa3b0cbb11c1c#in-app-messaging>In-APP
messaging

Later, there will be an option to have the app also submit push messages,
to broadcast to other users of the app (or to a specific user). This will
be done later...
<https://gist.github.com/matzew/7475652fa3b0cbb11c1c#api-access>API access

*Initial* focus is that the above functionality is *ONLY* accessable via
RESTful/HTTP APIs!

Later we will have a few more SDKs:

   - Client APIs (for Android, iOS)
   - Server APIs (send a push message out of your JavaEE app, without
   submitting (manually) the HTTP calls)












Cheers!
Matthias

[1] https://gist.github.com/matzew/7475652fa3b0cbb11c1c
-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130312/83af19d4/attachment.html