Hi all, On 13th February, the mobile team had a discussion with Kishanthan, Amila, Chamara and Nirmal regarding our deployment process (Previous mail thread subject: "Issue with tenancy specific files in app layer").
Basics In EMM, there are 4 jaggeryapps namely - mdm - mam - publisher - store Mostly used 2 apps are MDM and Store. How EMM contacts devices? The EMM connects to the enrolled devices in an asynchronous process. How this works is that the EMM server will contact the APNs<https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html>(Apple Push Notification server) or GCM <http://developer.android.com/google/gcm/index.html> (Google Cloud Messaging) which will inform the device to contact the EMM server. The reason as to why this is asynchronous is that when the EMM server contacts the APNs / GCM, the device might be switched off, it can be outside the network, the internet connection can be switched off, the device might be in idle state and etc... Device Monitoring process In EMM, the enrolled devices are constantly monitored based on a specific time interval. This is an important process since all the operation like policy compliance, apps installation, etc., depends on this. The EMM server dispatches messages to the enrolled device using the above explain mechanism. Tenancy The 4 apps distributed are placed in the repository/deployments/server/jaggeryapps which is the super tenant space. The multi-tenancy aspect of these apps are handled in the app layer (following the SaaS model). MDM app have below tenant specific files - config.json --> this has tenancy specific configuration like the domain name that should appear in the ios profile - ui.json --> tenant specific theme - license.txt --> This is the policy agreement that would appear when the user tries to enroll his / her device (Android / iOS) When we are adding a new tenant - currently these files have to be manually created in the filesystem (Refer Multi Tenancy in EMM Documentation<http://docs.wso2.org/display/EMM100/Multitenancy> ). Deployment layout First scenario is a user performing an operation from the web console. It will send a request via the ELB to the EMM and EMM will dispatch a message to GCM or APNS. Device will contact EMM via the ELB when it receives a notification from GCM or APNS. Second scenario is - the EMM server running a process and dispatching monitoring messages to GCM or APNS. Once the device get a monitoring notification it will contact EMM via the ELB. How the monitoring process starts will be explained below. Correlations Currently our monitoring thread implementation is based on JavaScript setInterval. Using correlation - a node will be selected as a policy monitoring member which will be the outgoing server. There are discussions on changing this to a Task Server based implementation. SVN DepSync and Publisher Basically dep sync will sync all the nodes to have the same app. The tenant related config files added in mdm will be propagated to all the nodes. Also our current publisher implementation relies on persisting uploaded files to the file system. Once a file is uploaded via the publisher - it will be added to the current node's file system. Afterwards DepSync will sync these files across all nodes. We are currently discussing on how to isolate these to a single storage app which is discussed in the architecture list [mail thread subject: Unified Storage Proposal]. -- *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
