[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)

Matthias Wessendorf matzew at apache.org
Fri Mar 15 06:56:09 EDT 2013 

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130315/98b2b148/attachment-0001.html

More information about the aerogear-dev mailing list