Hi Chan, IMO even without guaranteed delivery we can address the majority of the use cases of APNS usage which is 'push notification as a notification, not as data' .
Putting this to simple forms "As result of message mediation people get a notification on their iOS apps which makes them to open the app, and the app is responsible for keep the data in sync when a user uses the app." I think this has enough value to be added as an ESB connector. My suggested usage of feedback usage is not correct. Thank you for pointing that out :-) I had a chat with @Niranjan in the morning and I agree to the point that we should not encourage the users to use APN in ESB as a medium of transporting consistent data to an app (using proper documentation and restrictions in connector configs). I'm copying the mail to @Samisa, @Dushan and @Shevan to get their thoughts on the value of implementing the connector. Thanks /rushmin On Fri, Mar 28, 2014 at 7:36 AM, Chan <[email protected]> wrote: > Hi Rushmin, > I understand that you are looking at it from ESB perspective and other > vendors have also provided connectors for APNS on the ESB level [1]. But I > doubt the usefulness of such a connector. IMO we shouldn't build something > that doesn't solve a real problem or adds value. If someone wants to use > Push Notifications through the ESB they'll face the problem that I > mentioned earlier on. Shouldn't we think of the whole picture of APNS and > GCM and understand how people use it before building a connector? > > Small note - The APNS feedback service is not there to facilitate > guaranteed delivery [2]. APNS feedback service is used to stop sending > messages to unregistered devices. Also the prior validations that occurs in > the feedback service has nothing to do with delivery of the message. Also > @Niranjan added another important fact about APNS. If there is one message > available in APNS and the Connector sends another message with payload the > previous message gets replaced. An important fact to consider. > > [1] - http://mulesoft.github.io/apple-push-connector/mule/apple-push.html > [2] - > https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/CommunicatingWIthAPS.html > > > On Thu, Mar 27, 2014 at 11:12 PM, Niranjan Karunanandham < > [email protected]> wrote: > >> Hi, >> >> Accordingly to apple's documentation (Quality of Service) [1], APNs will >> try to deliver the notification but if the device is offline, the >> notification is stored for a limited period of time and once the device is >> online, it is delivered. In-addition to that, only one recent notification >> can for a particular application is stored. if there are multiple >> notifications when the device is offline, then only the last notification >> is kept and all others are discharged. >> APNs is mainly used to notify the user that a new messages are available >> for the app. Once the user opens the app, the device can communicate with >> our server to get the messages. In iOS 7 onwards, apple provides silent >> push notification (no sound or alert message), which can be used to trigger >> background task (within a certain time). The main thing to note here is >> that silent push notifications are rate-limited. >> >> >> [1] - >> https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html#//apple_ref/doc/uid/TP40008194-CH100-SW4 >> >> >> >> >> >> On Thu, Mar 27, 2014 at 10:18 PM, Chan <[email protected]> wrote: >> >>> Here is my take on the use-case. The ESB generates notifications based >>> on messages passed to the ESB. ESB triggers an APNS call to the device. The >>> point I am trying to make with Push Notifications is this - once the ESB >>> sends the message to the APNS - ESB has not track of it. APNS may or may >>> not contact the mobile app. First notification is sent to the device with >>> data. It doesn't get delivered. Second notification is made to the apns. It >>> gets delivered. CXO opens up the mobile app based on the second push >>> notification. He cannot see the 1st notification because it's depending on >>> APNS payload for data (Bad design). >>> >>> What we need is an MB model -where messages are stored in the server >>> side and ESB connector only sends send-to-sync messages to the device. >>> Device contacts MB to get the messages. >>> >>> Cheers~ >>> >>> >>> On Thu, Mar 27, 2014 at 8:54 PM, Rushmin Fernando <[email protected]>wrote: >>> >>>> Hi Dilshan, >>>> >>>> Good point. >>>> >>>> IMO the most prominent use case is pushing notifications to the devices >>>> which are registered for a specific app id. >>>> >>>> e.g. CXOs have a dashboard app installed. Based on some properties of >>>> messages to the ESB (business need) CXOs should get notified. Any CXO can >>>> have more than one device. Since they have this app installed each and >>>> every device get registered under the app id in whatever the system we are >>>> going to build/integrate with the connector. So when a notification is >>>> published to specific app id, all the devices under that app id get >>>> notified. >>>> >>>> I don't see taking 'users' in to the account as a part of the essential >>>> complexity in this point. It would provide more personalized push >>>> notifications indeed. But I think its out of our scope in this point. >>>> >>>> WDYT ? >>>> >>>> >>>> >>>> On Thu, Mar 27, 2014 at 4:48 PM, Dilshan Edirisuriya >>>> <[email protected]>wrote: >>>> >>>>> Hi Rushmin, >>>>> >>>>> Yes handling device token is out of our business I guess. As long as >>>>> you use it for dev purposes I believe it should be fine. Regarding the >>>>> token its based on the device. Each iOS application is bounded with an >>>>> application identifier. This can be wildcard application identifier as >>>>> well. You enable push notification to this app id from the iOS developer >>>>> portal. So overall for each person download the app from App Store or your >>>>> private app store is entitled for this APNS service. Next thing we need a >>>>> way to identify the device individually. Early days what we did was to >>>>> fetch the device Universal Device Identifier what we call as UDID or MAC >>>>> address of the devices (based on iOS versions). Now all are deprecated. >>>>> Hence there is no way to get a proper device identity at the server end >>>>> (FYI if you are using MDM you can get the UDID, MAC etc.). Then the better >>>>> solution would be to link these devices to the user. Let say there is user >>>>> A with his iPhone X and iPad Y. When the access the APNS server through >>>>> his >>>>> X and Y devices there will be 2 token generated by APNS. Hence when the >>>>> server needs to send push notifications to the user A server should be >>>>> wise >>>>> enough to send the message both to X and Y devices by looking at the >>>>> devices of User. Inorder to identify the app itself you will need that >>>>> application identifier or similar configured in the ESB as you have >>>>> mentioned above. >>>>> >>>>> To reply on the EMM integration yes we have done both the normal push >>>>> and MDM push. This APNS component need to be a orbit bundle which can be >>>>> used by any product when necessary. I will do that part so you can use it. >>>>> >>>>> @Chan The scenario is to accommodate the users who need to make use of >>>>> APNS through ESB. If APNS is not guaranteed delivery then there is nothing >>>>> can be done from ESB end. This is just a way to offer the same service as >>>>> a >>>>> connector. The developer who does this aware that it is not guaranteed >>>>> delivery and will work accordingly. Regarding the delivery theactual data >>>>> its based on the data set. There is a limitation to this data size. Its >>>>> used for notifying the user in most occasions. Even how Facebook uses is >>>>> to >>>>> notify the user and ask the user to open the app to get the rest of the >>>>> updates. But this doesnt mean that you cannot go beyond that and use it as >>>>> a feature like a push notification chat by restricting the data length to >>>>> max limit. There are plenty of apps which does this. The major difference >>>>> of this with MDM push is that MDM push connects to the server >>>>> automatically >>>>> when the device is wokenup whereas in this user has to tap the >>>>> notification >>>>> and open the app to get the updates. >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Dilshan >>>>> >>>>> >>>>> >>>>> On Thu, Mar 27, 2014 at 2:40 PM, Chan <[email protected]> wrote: >>>>> >>>>>> Let me be more clear into what I am saying. Push Notifications are >>>>>> sent from server to the device notifying that there is a message >>>>>> available. >>>>>> That' the general architecture pattern of usage and violating that >>>>>> architecture pattern will break Guaranteed Delivery. If someone used the >>>>>> APNS connector believing that the messages sent via the ESB connector is >>>>>> going to be definitely delivered by APNS - it will break his whole >>>>>> application. Let's not let people shoot themselves in the foot. >>>>>> >>>>>> I agree that there are edge cases of push notifications being used to >>>>>> deliver actual data but that's not the real use of it. For example when >>>>>> some comment on a Facebook photo of mine - iPhone shows a notification on >>>>>> the lock screen stating the name of the user who wrote the comment. When >>>>>> I >>>>>> click on the Facebook app - it connects to the Facebook server to >>>>>> actually >>>>>> get the new updates. This can be experimented while putting the phone to >>>>>> air plane mode and going to Facebook app. >>>>>> >>>>>> As for Rushmin's comments - I agree there is a configuration that is >>>>>> needed. For example usage - I want to send a push notification to an app >>>>>> - >>>>>> I will contact the ESB and give him the APNS certs and ids needed. >>>>>> Afterwards I will send notifications based on user and device (prior to >>>>>> this user's device has to be registered to receive notifications as >>>>>> well). >>>>>> EMM hasn't generalized this bit of registration since we already have a >>>>>> device registration. We need to clearly think from the use case >>>>>> perspective >>>>>> to understand the actual problem. @Rushmin can you list down few use >>>>>> cases >>>>>> of the APNS connector for ESB? End to end use cases that address the >>>>>> devices registration as well. >>>>>> >>>>>> (For the record I am not thinking of MDM push because there is no >>>>>> conceptual difference between MDM push and APP push). >>>>>> >>>>>> Cheers~ >>>>>> >>>>>> >>>>>> On Thu, Mar 27, 2014 at 2:30 PM, Rushmin Fernando >>>>>> <[email protected]>wrote: >>>>>> >>>>>>> Hi Chan and Dilshan, >>>>>>> >>>>>>> Thank you for your feedback. Please find my comments inline. >>>>>>> >>>>>>> >>>>>>> On Thu, Mar 27, 2014 at 12:59 PM, Dilshan Edirisuriya < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Your overall proposed architecture on the APNS looks good for me. >>>>>>>> Here are my comments on this. >>>>>>>> >>>>>>>> ================ >>>>>>>> This is the basic connector. Users are allowed to configure the >>>>>>>> connector with one or more device tokens and other push notification >>>>>>>> fields >>>>>>>> such as alert, badge and sound. >>>>>>>> >>>>>>>> Usage : This functionality only works fine when the number of >>>>>>>> devices is static. When it is dynamic then additional manual effort is >>>>>>>> needed to edit the device tokens in the connector configuration. >>>>>>>> ================ >>>>>>>> >>>>>>>> >>>>>>>> IMO you cannot add any device tokens to the configuration. Device >>>>>>>> token is generated when the device is registering in the APNS. This >>>>>>>> token >>>>>>>> can be differ if you delete the app and reinstall. So the generation of >>>>>>>> this token is not guaranteed. Hence as you have suggested there needs >>>>>>>> to be >>>>>>>> a REST feed which consumes this identifier and save it in somewhere >>>>>>>> else if >>>>>>>> there is a device token generation at the device end. I believe this >>>>>>>> should >>>>>>>> not be a function in ESB to store these things. Just route the device >>>>>>>> token >>>>>>>> along with a some user id through ESB to the external system and ask >>>>>>>> the >>>>>>>> external system to save it. They way the save is up to them based on >>>>>>>> their >>>>>>>> implementation at device end. Allow them to use the payload which can >>>>>>>> be >>>>>>>> sent from the device end. >>>>>>>> >>>>>>> >>>>>>> I agree with this. Configuring the connector with device tokens is >>>>>>> not a idea for prod use. But I made it a milestone as it would help to >>>>>>> test >>>>>>> the combination of ESB APN connector component wiring and APN service >>>>>>> connectivity. But its not production grade for sure :-) >>>>>>> >>>>>>> Initially I was thinking of having no dependencies like external >>>>>>> storage systems since the connector is not core part of the ESB. But I >>>>>>> agree with the point that we should maintain the consistency among our >>>>>>> products and not replicate functionality. To be honest my preference is >>>>>>> having an adapter for a vendor like Push IO and Urban Airship, so that >>>>>>> we don't need to manage devices tokens at all. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> ================ >>>>>>>> >>>>>>>> >>>>>>>> 1) There should be a way of adding an entity for each app the that >>>>>>>> entity will contain an app id and APN certificates. When the devices >>>>>>>> send >>>>>>>> self registration requests these device tokens too will be persisted >>>>>>>> in the >>>>>>>> app entity. >>>>>>>> >>>>>>>> *Problem* - *Whats the best way of persisting these info in ESB >>>>>>>> and is there any custom schema based forms to capture information like >>>>>>>> the >>>>>>>> app id and certificate info ?* >>>>>>>> >>>>>>>> >>>>>>>> ================ >>>>>>>> >>>>>>>> Please see my above comments. In any means I don't think this needs >>>>>>>> to be saved in ESB. Just delegate that to the external party by >>>>>>>> allowing it >>>>>>>> to be routed through ESB. Also if a user has multiple devices there >>>>>>>> will be >>>>>>>> multiple tokens. >>>>>>>> >>>>>>>> ================ >>>>>>>> >>>>>>>> >>>>>>> Please see the above comment for not saving device tokens in ESB. >>>>>>> >>>>>>> I dont get "Also if a user has multiple devices there will be >>>>>>> multiple tokens. " part. AFAIK APN clients are app id based rather >>>>>>> than being user based. >>>>>>> >>>>>>> As a reply to Chan's commment on this : APN are app based. So only >>>>>>> storing device tokens is not enough. Users should be able to create and >>>>>>> entry, give it an id( may be the bundle id of the app), upload app >>>>>>> specific >>>>>>> APN certificates using a UI and then use the app id to send the self >>>>>>> registration request using iOS. Does EMM support this ? >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Candidates for the client library are JavaPNS 2.2 [3] and java-apns >>>>>>>> [4]. >>>>>>>> >>>>>>>> ================ >>>>>>>> >>>>>>>> Only use the notnoop java-apns. We have discussed this earlier. >>>>>>>> Other library you cannot ship according to its license. Later yes you >>>>>>>> can >>>>>>>> have push io or urban airship. But these things are introduce for the >>>>>>>> purpose of ease since with less configurations you can enable support >>>>>>>> for >>>>>>>> multiple platforms. If you implement connectors for major mobile >>>>>>>> platforms >>>>>>>> like iOS, Android, Windows, BB then I dont see a clear reason to >>>>>>>> support >>>>>>>> them since those are just push services which also uses the underline >>>>>>>> platform push technologies. If you implement so any user can make use >>>>>>>> of >>>>>>>> the services through the ESB connector. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Noted the licensing part :-) We are yet to decide the app/device >>>>>>> info storage part. >>>>>>> >>>>>>> >>>>>>>> Commenting on Chans comments. >>>>>>>> >>>>>>>> ================ >>>>>>>> >>>>>>>> Also there is a known misconception about usage of Push >>>>>>>> Notifications. Push Notification itself will not have data (there is an >>>>>>>> exception for this) - push notification is a signal for the iOS device >>>>>>>> to >>>>>>>> contact a provider to get new data that's available (it's called >>>>>>>> Send-to-Sync by GCM). I think we need to re-think the whole picture >>>>>>>> when it >>>>>>>> comes to Push Notifications. >>>>>>>> >>>>>>>> ============== >>>>>>>> >>>>>>>> Chan you are talking about MDM push notifications here. MDM push >>>>>>>> notifications are something different than the normal push >>>>>>>> notifications. >>>>>>>> In MDM it just uses push technology to wake up the device allowing it >>>>>>>> to >>>>>>>> communicate with the registered MDM server. The purpose of the normal >>>>>>>> push >>>>>>>> is to send notifications directly to the device. So this involves a >>>>>>>> payload. You can set badges, sounds, priority etc. to this. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Both statements are correct. APNs do support a small payload along >>>>>>> with notification attributes such as badge, sound and alert. So its up >>>>>>> to >>>>>>> the user to use it as a data (very small data chunks) or as a trigger. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> =============== >>>>>>>> >>>>>>>> >>>>>>>> Shall we make the apns connectivity part in a way that is abstract >>>>>>>> to the connector? In the EMM product - we use apns (app push & mdm >>>>>>>> push) - >>>>>>>> it would better if we can leverage a single component through out the >>>>>>>> platform. >>>>>>>> >>>>>>> >>>>>>>> ============= >>>>>>>> >>>>>>>> Yes we have implemented this in EMM. That supports both normal push >>>>>>>> notifications and mdm push notifications. Yes I will make this an orbit >>>>>>>> bundle so you can use this directly. >>>>>>>> >>>>>>>> >>>>>>> +1 for this. I'll have a look at EMM to get an idea. >>>>>>> >>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Dilshan >>>>>>>> >>>>>>>> >>>>>>>> <https://github.com/notnoop/java-apns> >>>>>>>> >>>>>>>> Dilshan Edirisuriya >>>>>>>> Senior Software Engineer - WSO2 >>>>>>>> Mob: + 94 777878905 >>>>>>>> http://wso2.com/ >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Rushmin Fernando >>>>>>> Technical Lead >>>>>>> Mobile : +94772310855 >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Chan (Dulitha Wijewantha) >>>>>> Software Engineer - Mobile Development >>>>>> WSO2Mobile >>>>>> Lean.Enterprise.Mobileware >>>>>> * ~Email [email protected] <[email protected]>* >>>>>> * ~Mobile +94712112165 <%2B94712112165>* >>>>>> * ~Website dulitha.me <http://dulitha.me>* >>>>>> * ~Twitter @dulitharw <https://twitter.com/dulitharw>* >>>>>> *~SO @chan <http://stackoverflow.com/users/813471/chan>* >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Dilshan Edirisuriya >>>>> Senior Software Engineer - WSO2 >>>>> Mob: + 94 777878905 >>>>> http://wso2.com/ >>>>> >>>> >>>> >>>> >>>> -- >>>> Rushmin Fernando >>>> Technical Lead >>>> Mobile : +94772310855 >>>> >>> >>> >>> >>> -- >>> Chan (Dulitha Wijewantha) >>> Software Engineer - Mobile Development >>> WSO2Mobile >>> Lean.Enterprise.Mobileware >>> * ~Email [email protected] <[email protected]>* >>> * ~Mobile +94712112165 <%2B94712112165>* >>> * ~Website dulitha.me <http://dulitha.me>* >>> * ~Twitter @dulitharw <https://twitter.com/dulitharw>* >>> *~SO @chan <http://stackoverflow.com/users/813471/chan>* >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> >> *Niranjan Karunanandham* >> Senior Software Engineer - WSO2 Inc. >> WSO2 Inc.: http://www.wso2.com >> M: +94 777 749 661 <http:///> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Chan (Dulitha Wijewantha) > Software Engineer - Mobile Development > WSO2Mobile > Lean.Enterprise.Mobileware > * ~Email [email protected] <[email protected]>* > * ~Mobile +94712112165 <%2B94712112165>* > * ~Website dulitha.me <http://dulitha.me>* > * ~Twitter @dulitharw <https://twitter.com/dulitharw>* > *~SO @chan <http://stackoverflow.com/users/813471/chan>* > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Rushmin Fernando Technical Lead Mobile : +94772310855
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
