synapseindia mobile apps deployment framework architecture
Post on 19-Jul-2015
Embed Size (px)
SynapseIndia Mobile Apps Deployment framework architecture
*17.02.2006Deployment framework architecture The MTJ provides an Deployment framework that supports the existing SDK Emulators and phones runtimes. The framework publishes an deployment interface, that capsulate (hides) the actual runtime environments and protocols. The framework separates the different deployment low-level services to own components (like UEI, OTA, etc.) with supporting existing proprietary emulator and phone access (marked as X and Z). It also provides a new development branch to the OBEX based deployment, which can be used e.g. towards to MAC OS environment. Thus this requires that the needed protocols / protocol wrappers are available.MTJ IDE environment ZSDK / Emulator context (Nokia, Win32 OS)InterfaceS40S60
Deployment FrameworkExtension pointInterfaceSDK / Emulator (Vendor X)O T A U E I X
*17.02.2006Mobile Vendor specific viewEclipseSDK / Emulator (Vendor X)Vendor XSDK EmulatorPlug-in The MTJ provides an Deployment framework that supports the existing SDK Emulators and phones runtimes The framework publishes a Device Platform -interface, that capsulate (hides) the actual runtime environments and protocols. The framework separates the different vendors products to own plug-ins MTJPlug-in
DevicePlatformExtension pointSDK / Emulator (Vendor Y)Vendor YSDK EmulatorPlug-inSDK / Emulator (Vendor Z)Vendor ZSDK EmulatorPlug-inVendor XReal DevicePlug-inReal Device (Vendor X)Vendor YReal DevicePlug-inReal Device (Vendor Y)
*17.02.2006Mobile vendor specific view detailsDifferent mobile vendors can use their existing emulators and add the deployment (emulator) specific plug-in to the MTJ environment. The emulator specific plug-in may be even in binary format, if it needs to protect some internal implementation or specification.The emulator specific plug-in uses the MTJ generic API and also contributes to the MTJs deployment frameworks extension point.The deployment framework could provide an template from such plug-in that helps to other vendors to tie up their specific solutions.The deployment framework supports also that the emulator is discovered by manual entering the location. There could be a dynamic plug-in, that ties the discovered emulator to the deployment framework.The deployment framework can provide also other extension points, that enables others to extend e.g. the emulator specific properties, UIs etc.The deployment framework provides a plug-in template for existing emulators, which can dynamically be attached to wrap the specific emulator.
*17.02.2006Deployment framework plug-insVendor Z Real Device Plug-inSDK / Emulator (Vendor X)Vendor X SDK EmulatorPlug-in U E ISDK / Emulator (Vendor Y)Vendor Y SDK EmulatorPlug-in X E IVendor Y Real Device Plug-inReal Device (Vendor Y)Vendor X Real DevicePlug-inReal Device (Vendor X) O B E XSDK / Emulator (Vendor Z)Vendor Z SDK EmulatorPlug-inXHTTP/FTP serviceReal Device (Vendor Z) Device Platform plug-ins have several different implementations Device Platform plug-ins are responsible of the communication protocols between MTJ environment and Emulators / Real Devices The plug-ins also store all config data. F. ex. Emulator plug-in stores the Emulator SDK root directory itself
UEI = Unified Emulator Interface XEI = Extended Emulator Interface (Nokia proprietary) X = Proprietary Emulator InterfaceMTJ plug-in wrapperMobile vendors devices
*17.02.2006Deployment framework designIntegrating to the existing SDK Emulators: Deployment frameworkEnables adding a new SDK Emulator by manually entering the location or by local hard drive browsing (typical case for existing emulators).Hides the used targeted runtime environments behind a few deployment interfacesSimplifies the deployment process against the device / emulator variationGeneralizes the deployment management by encapsulating the SDK Emulator dependencies to a separate plug-ins, thus enabling it to publish its own specific functionality.
Integrating to new SDK Emulators, which do have a specific plug-in:Deployment frameworkIf the SDK Emulator has own deployment plug-in and the plug-in does follow the Deployment framework extension rules, its automatically instantiatedDeployment framework instantiates Deployment component and calls its methods via deployment interfaceDeployment component plug-in Implements the Deployment frameworks interfaceContributes to the Deployment frameworks extension pointMay also extend some SDK Emulator specific services to the Deployment framework
*17.02.2006Deployment framework Model Device PlatformDeviceEmulatorDeviceRealDevice Runtime PlatformDefinition1..n1 Target environments are seen as Device Platforms by the MTJ environment. Device Platform contains one or more Device instances. MTJ plug-in doesnt know if the Devices are device emulators or real devices because the plug-in extension point API hides all implementation details. Device instance defines the Runtime Platform that its capable to run on.
*17.02.2006Deployment framework Model (cont.)
DeploymentMIDletDeploymentCDCDeployment Deployment interface is generic representation of a entity that is send from MTJ environment to Device Platform instances. Realization of a deployment can be MIDlet, CDC, MEGlet or Resource deployment (or something else). So the realization is created from source application definitions and f. ex. MIDlet project deployment consists of Application JAR and JAD files. Target Device Platform knows, whats inside the received deployment and how to handle it. MEGletDeploymentResourceDeploymenti/f
*Signing and ObfuscationSigning and Obfuscating internal architecture
*17.02.2006Signing architectureThere is a SecurityManager, that manages the keys and certificates in the IDE environment globally.Each project can configure the signing options and parameters against the actual needs.The Signing Provider implements the actual signing and it can be used through e.g. the Ant scripts.
*17.02.2006Obfuscating architectureIt is a well known fact that Java Class (bytecode) files can be easily reverse-engineered because Java compiler leaves a lot of such information into bytecode that helps the reverse-engineering task. Code obfuscation is one protection tool for Java code to prevent reverse engineering. Code obfuscation makes programs more difficult to understand, so that it is more resistant to reverse engineering. Obfuscation techniques fall into three groups: Layout Obfuscations Layout Obfuscations modify the layout structure of the program by two basic methods: renaming identifiers and removing debugging information. Almost all Java obfuscators contain this technique.Control Obfuscations Control Obfuscations change the control flow of the program.Data ObfuscationsData Obfuscations break the data structures used in the program and encrypt literal. The MTJ enables to use existing Obfuscator -products through an wrapper plug-in (Obfuscation Provider), that can be further tailored.
*Backup slides - GUIMobile Visual Editor architecture
*17.02.2006Visual IDE environment in generalEclipse PlatformIDEScreen EngineLauncher / EmulatorGraphical EditorCode / Resource EditorProperty SheetOutline ViewerSource code, resource files, etc.UI, WYSIWYGTrace, profile, debugThe RAD IDE environment is having some clear elements, like the core IDE graphical and code editor, property sheet and outline viewer for IDE environment objects. Also the graphical editor uses the screen engine for creating the actual graphical UI presentation (like WYSIWYG). Also the mobile emulators / SDKs are providing the ability to launch the applications.
*17.02.2006VE Internal Component ArchitectureEclipse Platform Eclipse Visual Editor FrameworkJava coreJFC EditorSWT EditorJava Element Model (JEM)Common Diagram Model (CDE)GEFEMFJava Code Generation AdapterThe Eclipse Visual Editor framework provides a flexible GUI framework, which can be quite easily extended to e.g. mobile domain. The current desktop version supports JFC and SWT GUI editors with full set of UI widgets. The actual screen rendering is done in separate rendering engine.Internally VE uses EMF in CDE and models the Java source in JEM.
*17.02.2006Mobile Visual Editor GUI ComponentsMTJ Screen EngineScreen Rendering ContextEclipse MTJ IDEEclipse VEEclipse PlatformMTJ Mobile ExtensionGEF EditorPartUI VE ModelCustom Mobile proxy componentsMobile eSWT proxy componentsMobile CLDC proxy componentsBeanInfo AdapterCustom Screen Rendering EngineMTJ CDLC UI componentsMTJ eSWT UI componentsMTJ eSWT UI componentsCustom UI Look & Feel
*Backup slides Milestone Plan
*17.02.2006MTJ Milestone Plantbd