Another point I remembered was that we can have a connector to APNS and GCM with the components.
On Tue, Feb 25, 2014 at 3:34 PM, Sameera Jayasoma <same...@wso2.com> wrote: > Had a small chat with couple of team members of this task. Here is my +1 > for this change. > > But you guys have to fix the package incompatibilies in the platform. Push > these changes to Carbon 4.3.0 release as well. > > > On Mon, Feb 24, 2014 at 12:35 PM, Dilshan Edirisuriya <dils...@wso2.com>wrote: > >> Hi, >> >> We have set of java components in EMM which is referenced as libraries >> from the Jaggery app. You can find them here [1]. >> >> These are the components and its usage. >> >> 1) GCM - Google cloud messaging. This is a wrapper around gcm library >> provided by Google. We have created a orbit for this as com.wso2.mobile.gcm >> since we have extended it. >> >> 2) iOS mdm - This component will responsible for iOS enrollment. This has >> covered the flow in [2]. This involves an inbuilt SCEP (Simple Certificate >> Enrollment Protocol) and a CA (Certificate Authority) components. Here the >> component part will only act as a SCEP server. I have attached a possible >> flow chart for the enrollment which only covers the major blocks in the >> enrollment. >> >> Also this component responsible for reading the mdm-config.xml file which >> resides in repository/conf directory. This consist of MDM keystore paths, >> scep urls, paths of pfx files etc. >> >> 3) iOS APNS - This is used for apple push notification services APNS. >> This has 2 varieties as mdm push and normal push. Further documentation can >> be found at [3]. >> >> 4) iOS payload generator - This will manipulate the operations of the >> MDM. Each operation consist of a corresponding xml payload (plist format). >> >> FYI - Right now as I was instructed, this has been done as a static xml >> file. But since in some operations the payload is dynamic we need a proper >> xml generation code implemented here in the future. >> >> 5) Manifest utils - This does the Android xml parsing. >> >> >> We have used these as Java libraries (as we instructed in the very first >> meeting we had) and from the Jaggery code we invoke them as JS modules. >> >> Right now we feel that these components needs to go under components in >> our svn/git structure due to following reasons. >> >> 1) We use some 3rd party libraries like bouncy castle. In our scenario we >> had to make use of the latest bouncy castle library. So when including that >> as a lib it ends up with OSGI issues since form the platform level some >> components exports it as well. The version of the exported libraries are >> bit old. Hence we had to patch those libraries and apply them in the EMM >> pack. So each time when there are new patches we have to follow these >> steps. This is just a one library scenario. So as a solution either we have >> to upgrade the libraries in platform or somehow use the platform exported >> version in EMM. >> >> 2) SCEP and CA should be moved into IS. I believe these are not part of >> the EMM scope. Ideally these should be moved to IS where it is the most >> suitable. If we do so we need a proper wrapper layer around it to handle >> the enrollment. >> >> 3) We will have more features written in Java. In next milestone we would >> go for the MAC OSX management features. For this a separate provisioning >> mechanism will be used but it will be bit similar to the approach we have >> followed for iOS. >> >> 4) Integration with Task server will be needed for policy monitoring. In >> the current implementation what we have done is to use a set interval >> function in Jaggery to executing the monitoring in X time interval. In a >> clustered environment we keep this feature in 1 node and comment out the >> rest. By next milestone we will be most likely to introduce time based >> policies and monitoring mechanisms. >> >> >> According to the above needs let us know whether we need to go for >> components or whether we should continue using these as libs which is >> included in components/lib. >> >> >> [1] - https://github.com/wso2/emm_utilities >> >> [2] - >> https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/iPhoneOTAConfiguration/OTASecurity/OTASecurity.html#//apple_ref/doc/uid/TP40009505-CH3-SW1 >> >> [3] - >> https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html >> >> >> Regards, >> >> Dilshan >> >> -- >> Dilshan Edirisuriya >> Senior Software Engineer - WSO2Mobile >> Mob: + 94 772245502 >> http://wso2mobile.com/ >> >> >> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Sameera Jayasoma, > Architect, > > WSO2, Inc. (http://wso2.com) > email: same...@wso2.com > blog: http://sameera.adahas.org > twitter: https://twitter.com/sameerajayasoma > flickr: http://www.flickr.com/photos/sameera-jayasoma/collections > Mobile: 0094776364456 > > Lean . Enterprise . Middleware > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Chan (Dulitha Wijewantha) Software Engineer - Mobile Development WSO2Mobile Lean.Enterprise.Mobileware * ~Email duli...@wso2.com <duli...@wso2mobile.com>* * ~Mobile +94712112165* * ~Website dulithawijewantha.com <http://dulithawijewantha.com/>* * ~Blog blog.dulithawijewantha.com <http://dulichan.github.io/chan/>* * ~Twitter @dulitharw <https://twitter.com/dulitharw>*
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
