[aerogear-dev] AeroGear Unified Push - Abstraction layer for "push enabled apps" (was: Re: [AG Push] BASIC (and INITAL) use cases of the Unified Push Server)

tech4j at gmail.com tech4j at gmail.com
Fri Mar 15 08:28:03 EDT 2013 

On Fri, Mar 15, 2013 at 8:25 AM, Matthias Wessendorf <matzew at apache.org>wrote:

>
>
> On Fri, Mar 15, 2013 at 1:15 PM, tech4j at gmail.com <tech4j at gmail.com>wrote:
>
>> A few small comments, because I think this is looking pretty good.
>>
>> * At first glance I like the idea of having it be a registry instead of a
>> manager.  In some ways that makes it more obvious this a logical construct.
>>
>> * Another use case:  "Other services inside of JBoss could use the push
>> manager/registry, for example the admin console, Errai, drools, etc..."
>> ** I.e. not just for end user apps
>>
>
>
> I think that's what I tried to address with this statement: "We want that
> any (JBoss/AeroGear powered) mobile application, that is backed by JBoss
> technology, is able to easily work with push messages. For a JBoss "backend
> application" it should be as simple as possible, to send messages to its
> different mobile clients"
>
> ==> should not be tied to a specific backend; For instance a JSF managed
> bean you use the "Sender" as well - to push out messages to 'its'
> configured mobile apps (on the registration)
>

ok, then yes, same page


>
>
>>
>> * The non-native push (JS, "connected" apps, etc...) imo would/should be
>> separate and part of AeroGear proper.  I think having both functions in
>> this one shared service would make it too complex, and hard to cover other
>> groups use-cases.  As I see it for AeroGear - we receive a
>> msg/event/trigger that we want to send to clients.  The API allows
>> developers to say "send msg to x, y, z users/devices".  AeroGear checks for
>> any apps that are "connected" and sends a non-native push msg to those
>> clients.  AeroGear then determines who did not get a "connected" msg (that
>> may be tricky), and uses the API your defining to send those users native
>> push msg.
>>
>
> You mean breaking into two components?
> - native push
> - web based push
>
> and an overall API on top that 'aggregates'?
>

Yes, and yes :-)


>
>
>>
>> ** The API would have a way to set only "connected", only native, etc...
>> as well.
>>
>> * In the future and maybe as a POC that this can work with non-aerogear
>> clients we could see about getting push messages setup with Christos' JBoss
>> admin app with this.  Not a priority, but an idea :-)
>>
>>
>>
>>
>> On Fri, Mar 15, 2013 at 6:56 AM, Matthias Wessendorf <matzew at apache.org>wrote:
>>
>>>
>>>
>>> On Fri, Mar 15, 2013 at 11:27 AM, Sebastien Blanc <scm.blanc at gmail.com>wrote:
>>>
>>>>
>>>>
>>>> On Fri, Mar 15, 2013 at 10:58 AM, Matthias Wessendorf <
>>>> matzew at apache.org> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, Mar 15, 2013 at 10:48 AM, Sebastien Blanc <scm.blanc at gmail.com
>>>>> > wrote:
>>>>>
>>>>>> Great Job,
>>>>>> see my comments inline.
>>>>>>
>>>>>> On Fri, Mar 15, 2013 at 10:07 AM, Matthias Wessendorf <
>>>>>> matzew at apache.org> wrote:
>>>>>>
>>>>>>> As discussed on the earlier theard, we have some raw APIs... Below a
>>>>>>> little summary:
>>>>>>>
>>>>>>> We have a UnifiedPushManager(.java) defined, which is basically a
>>>>>>> registry for "push enabled" apps (PushApplication.java). Such a
>>>>>>> PushApplication is a logical construct on the backend which is
>>>>>>> allowed/enabled to send notifications to mobile clients. One example could
>>>>>>> be the "Twitter Backend" (e.g. for push notification on direct messages).
>>>>>>>
>>>>>> As you said the manager is here more a registry than a manager in the
>>>>>> current state, maybe we should have a *PushApplicationRegistry*interface which has as only responsibility to hold the register state,
>>>>>>
>>>>>
>>>>> Can you gist ?
>>>>>
>>>>
>>>> Take a look at my fork
>>>> https://github.com/sebastienblanc/ag-unified-push-api/tree/registry ;)
>>>>
>>>>>
>>>>>
>>>>>
>>>>>>  the implementation of the registry will connect to the chosen
>>>>>> persistence unit (JPA/Mongo/Oracle ...).
>>>>>>
>>>>>
>>>>> Not sure I really want to that - now :) I am (for first iteration)
>>>>> fine to have something running, instead of being that flexible and be able
>>>>> to go with any existing "data source" :-)
>>>>>
>>>>
>>>> Well, for sure, for the first iteration we will provide a default
>>>> implementation.
>>>>
>>>>>
>>>>>
>>>>>> This way we could have a concrete implementation of the *
>>>>>> UnifiedPushManager* than can be used by different backend/customers
>>>>>> (think DRY) , they just have to inject the needed *
>>>>>> PushApplicationRegistry* implementation.
>>>>>>
>>>>>
>>>>> Not sure what exactly you mean - perhaps a gist / pseudo code is
>>>>> helpful here too ?
>>>>>
>>>>
>>>> Again, my fork should help you understanding
>>>> https://github.com/sebastienblanc/ag-unified-push-api/tree/registry but
>>>> basically, it is the same as your code except I apply the delegate pattern.
>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Now each of the PushApplication can have a few mobile applications,
>>>>>>> that receive those push messages (e.g. the offical Twitter iOS client and
>>>>>>> the offical Twitter Android client). These "mobile apps" are represented -
>>>>>>> on the server - with the MobileApplication.java class. Usually
>>>>>>> there is only one iOS app and one Android... *BUT* imagine the case
>>>>>>> of a "paid/premium app" versus a free app (e.g. something like
>>>>>>> TwitterPro-iOS and Twitter-free-iOS... *NOTE*: there is NOTHING
>>>>>>> like that, I just made these two apps up, to explain the concept).
>>>>>>>
>>>>>>> Of course there are several installations of the iOS(and Android...)
>>>>>>> app. Each installation is represented with the
>>>>>>> MobileApplicationInstance.java class. Each installation is
>>>>>>> registered by a "device registration service": The actual app on the device
>>>>>>> submits its token/regId (and some other infos) to a HTTP endpoint....
>>>>>>>
>>>>>>> Now the UnifiedPushManager(.java) is the central API to *register* PushApps
>>>>>>> and their mobile views, including (device)registration of installations (->
>>>>>>> MobileApplication and MobileApplicationInstance).
>>>>>>>
>>>>>>> Any backend app, can now use the *Sender API* to actually send the
>>>>>>> message to these different devices/appications, from the
>>>>>>> UnifiedPushManager, assuming they have permission :-)
>>>>>>>
>>>>>>> A simple example is here (java code for registration AND sending);
>>>>>>> Note it's a Unit test.......:
>>>>>>> https://github.com/matzew/ag-unified-push-api/blob/master/src/test/java/org/jboss/aerogear/push/UnifiedPushManagerTest.java#L41-L81
>>>>>>>
>>>>>>
>>>>>> Maybe the *Sender* interface should be an attribute of the *
>>>>>> PushManager*, the customer can set his *Sender* impl
>>>>>> (pushManager.setSender(...) )  and the UnifiedManager act as a facade for
>>>>>> the "sending" actions.
>>>>>>
>>>>>
>>>>>
>>>>> Hrm - you really think folks will write their own "Senders"? I
>>>>> think... if they want to add support for "Windows Mobile", they just have
>>>>> to extend the abstract MobileApplicationImpl and implement it's send() to
>>>>> talk to the Windows Push infrastrucuture
>>>>>
>>>>
>>>> Again, we will provide a default sender implementation. But I seee
>>>> indedd issues, having a single senders for different platforms , hum, let
>>>> me think about this ;)
>>>>
>>>
>>>
>>> the Sender() is an aggregate of the different mobile Application's
>>> "send()" - it will enqueue the message for the different platforms
>>>
>>>
>>> thanks for the feedback - will check ur fork
>>>
>>>
>>> -M
>>>
>>>
>>>
>>>>
>>>>>
>>>>> PERHAPS... just using interfaces was confusing  - there will be
>>>>> concrete classes (first impl is in the TEST project (see other thread)),
>>>>> but the interfaces are a highlevel view of the "domain model"
>>>>>
>>>>>
>>>>>>
>>>>>>> <https://gist.github.com/matzew/73d478a42c093e21a6b9#so-far-so-good---but-why-this-abstraction->So
>>>>>>> far, so good - but why this abstraction ????
>>>>>>>
>>>>>>> *Goal*: We want that any (JBoss/AeroGear powered) mobile
>>>>>>> application, that is backed by JBoss technology, is able to easily work
>>>>>>> with push messages. For a JBoss "backend application" it should be as
>>>>>>> simple as possible, to send messages to its different mobile clients
>>>>>>>  <https://gist.github.com/matzew/73d478a42c093e21a6b9#some-scenarios>Some
>>>>>>> Scenarios
>>>>>>>
>>>>>>>    - MyWarehouseInc-backend can send messages to different
>>>>>>>    "customer" groups (e.g. discounts for only iOS (or only Android) users).
>>>>>>>    - MyInsuranceCorp-backend can send important "info messages" to
>>>>>>>    diffenrent variants of its mobile Applications (e.g. to the
>>>>>>>    MyInsuranceCustomer-APP (regardless of the OS) AND to the app for their own
>>>>>>>    agents (MyInsuranceAgent-APP))
>>>>>>>    - MyPublishing-Company-backend sends updates to all of its apps
>>>>>>>    (free and premium - regardless of the mobile OS). Advanced content is only
>>>>>>>    push to the paying customers...
>>>>>>>    - A company has different backends (small apps for different
>>>>>>>    tasks) - and these different backends could be able to reach all of the
>>>>>>>    company's mobile apps
>>>>>>>
>>>>>>> So... the Sender somewhat acts as a broker (for accessable apps on
>>>>>>> the 'registry' UnifiedPushManager)...
>>>>>>>
>>>>>>
>>>>>> Maybe we should define some kind of "Application" Collection, as
>>>>>> smart/specific  Java Collection implementation to be able to create easily
>>>>>> groups of apps etc .. just a rough idea that needs to be cleaned up ;)
>>>>>>
>>>>>
>>>>>
>>>>> Something like that would be neat, for more advanced queries /
>>>>> selection etc
>>>>>
>>>>
>>>> We could have a (very) simple query language specific for Push Apps,
>>>> like hibernate, we could query by example. In my fork you will see an
>>>> extremely basic Query object ...
>>>>
>>>>>
>>>>> Thanks for the feedback!
>>>>> -M
>>>>>
>>>>>
>>>>>>
>>>>>>> BTW... none!!!!!!! of the API names are final - happy to hear better
>>>>>>> names!!!
>>>>>>>
>>>>>>> Please provide feedback (here and on the other thread), for
>>>>>>> missing/wrong/good items.!
>>>>>>>
>>>>>>>
>>>>>>> Greetings,
>>>>>>> Matthias
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Mar 14, 2013 at 6:58 PM, Matthias Wessendorf <
>>>>>>> matzew at apache.org> wrote:
>>>>>>>
>>>>>>>> here is, including device registration:
>>>>>>>>
>>>>>>>>
>>>>>>>> https://github.com/matzew/ag-unified-push-api/blob/master/src/test/java/org/jboss/aerogear/push/UnifiedPushManagerTest.java#L41-L81
>>>>>>>>
>>>>>>>> All hammered in java... since this is a test - most of the code
>>>>>>>> will be executed, when interacting with HTTP endpoints of the thing;
>>>>>>>>
>>>>>>>> Yes, there is no JS application in the test - but we do have an
>>>>>>>> abstraction interface for it:
>>>>>>>>
>>>>>>>> https://github.com/matzew/ag-unified-push-api/blob/master/src/main/java/org/jboss/aerogear/push/application/ConnectedJavaScriptApplication.java
>>>>>>>>
>>>>>>>> Connected? Since only "online" JS clients are receiving message -
>>>>>>>> there no real "push to device" for the JS world...
>>>>>>>>
>>>>>>>> -Matthias
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Mar 14, 2013 at 3:41 PM, Matthias Wessendorf <
>>>>>>>> matzew at apache.org> wrote:
>>>>>>>>
>>>>>>>>> Pushed FIRST/TEST impl + actually test case.....
>>>>>>>>>
>>>>>>>>> https://github.com/matzew/ag-unified-push-api
>>>>>>>>>
>>>>>>>>> YEs.... I have 'xxx'd out the KEY and certs :)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Mar 14, 2013 at 11:04 AM, Matthias Wessendorf <
>>>>>>>>> matzew at apache.org> wrote:
>>>>>>>>>
>>>>>>>>>> My UNIT test looks (currently) like:
>>>>>>>>>>
>>>>>>>>>> https://gist.github.com/matzew/3d7f9915afd8f6705da5
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -M
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Mar 13, 2013 at 11:03 PM, Matthias Wessendorf <
>>>>>>>>>> matzew at apache.org> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Mar 13, 2013 at 10:06 PM, tech4j at gmail.com <
>>>>>>>>>>> tech4j at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I think this is look really good!
>>>>>>>>>>>>
>>>>>>>>>>>> Here some thoughts, and/or possible additional use-cases
>>>>>>>>>>>>
>>>>>>>>>>>> * How do we want to handle multiple devices for one user?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Instance of 'MobileApplicationInstance'; each device has (per
>>>>>>>>>>> app) a different token;
>>>>>>>>>>> What the apps do themselves, with multiple installs is something
>>>>>>>>>>> different.
>>>>>>>>>>>
>>>>>>>>>>> Twitter, for instance, sends the push-messages to EVERY device -
>>>>>>>>>>> but that's app specific sync
>>>>>>>>>>> (yes, i wish there was something like IMAP, for twitter)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> * How do we want to handle the other side of unified push
>>>>>>>>>>>> (non-native)?
>>>>>>>>>>>> ** Might just not be there yet, but want to make sure we're
>>>>>>>>>>>> still thinking the same thing :-)
>>>>>>>>>>>> ** Would there be an additional abstraction above this for that?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> some sub type of 'MobileApplication' can/will cover that "mobile
>>>>>>>>>>> web" (JS client) side:
>>>>>>>>>>>
>>>>>>>>>>> https://github.com/matzew/ag-unified-push-api/blob/master/src/main/java/org/jboss/aerogear/push/application/MobileApplication.java#L23
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> * I'm assuming there is no good way for apps to notify you when
>>>>>>>>>>>> they are uninstalled?
>>>>>>>>>>>> ** As a way of removing clutter in our tables.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> In apple land these are invalid tokens (see
>>>>>>>>>>> https://github.com/notnoop/java-apns/blob/master/src/main/java/com/notnoop/apns/ApnsService.java#L161
>>>>>>>>>>> )
>>>>>>>>>>> So, on a scheduled base they can be remove;
>>>>>>>>>>>
>>>>>>>>>>> Google has similar API (on their MulticastResult (returned by
>>>>>>>>>>> the sender))
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> * Push filtering - I would think IDM would be very good here.
>>>>>>>>>>>> ** Sending to roles, groups, etc...
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> have different users (==roles), but not spec'd out
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> ** When we store the device and app info what sub-system are
>>>>>>>>>>>> you thinking?
>>>>>>>>>>>> *** I know you were using mongo for some of the prototyping
>>>>>>>>>>>> *** Would be possible to abstract to the IDM?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> yes, it should be possible (desirable) to use IDM - but does not
>>>>>>>>>>> really matter
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks for the feedback!!!
>>>>>>>>>>>
>>>>>>>>>>> -Matthias
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Mar 13, 2013 at 12:58 PM, Douglas Campos <qmx at qmx.me>wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 13/03/2013, at 10:28, Matthias Wessendorf <
>>>>>>>>>>>>> matzew at apache.org> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> > ome more APIs, for some basic (initial) functionality:
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > https://gist.github.com/matzew/c5fbc23bc97dfead46e1
>>>>>>>>>>>>>
>>>>>>>>>>>>> I like the current form, but I'm sure we'll get asked about
>>>>>>>>>>>>> more OO(ish) APIs, like device.send(Message) - is this on the plans?
>>>>>>>>>>>>>
>>>>>>>>>>>>> > User/Dev enrollment can be addressed by (hopefully) reusing
>>>>>>>>>>>>> the ag-security.
>>>>>>>>>>>>>
>>>>>>>>>>>>> +1
>>>>>>>>>>>>>
>>>>>>>>>>>>> -- qmx
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> aerogear-dev mailing list
>>>>>>>>>>>>> aerogear-dev at lists.jboss.org
>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> blog: http://in.relation.to/Bloggers/Jay
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> aerogear-dev mailing list
>>>>>>>>>>>> aerogear-dev at lists.jboss.org
>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Matthias Wessendorf
>>>>>>>>>>>
>>>>>>>>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>>>>>>>>> sessions: http://www.slideshare.net/mwessendorf
>>>>>>>>>>> twitter: http://twitter.com/mwessendorf
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Matthias Wessendorf
>>>>>>>>>>
>>>>>>>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>>>>>>>> sessions: http://www.slideshare.net/mwessendorf
>>>>>>>>>> twitter: http://twitter.com/mwessendorf
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Matthias Wessendorf
>>>>>>>>>
>>>>>>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>>>>>>> sessions: http://www.slideshare.net/mwessendorf
>>>>>>>>> twitter: http://twitter.com/mwessendorf
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Matthias Wessendorf
>>>>>>>>
>>>>>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>>>>>> sessions: http://www.slideshare.net/mwessendorf
>>>>>>>> twitter: http://twitter.com/mwessendorf
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matthias Wessendorf
>>>>>>>
>>>>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>>>>> sessions: http://www.slideshare.net/mwessendorf
>>>>>>> twitter: http://twitter.com/mwessendorf
>>>>>>> _______________________________________________
>>>>>>> aerogear-dev mailing list
>>>>>>> aerogear-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> aerogear-dev mailing list
>>>>>> aerogear-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matthias Wessendorf
>>>>>
>>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>>> sessions: http://www.slideshare.net/mwessendorf
>>>>> twitter: http://twitter.com/mwessendorf
>>>>>
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>
>>>
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> sessions: http://www.slideshare.net/mwessendorf
>>> twitter: http://twitter.com/mwessendorf
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>>
>> --
>> blog: http://in.relation.to/Bloggers/Jay
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
blog: http://in.relation.to/Bloggers/Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130315/3e7c61f8/attachment-0001.html

More information about the aerogear-dev mailing list