Historical move by both Apple and Microsoft to work together ripples the Online Mobile Search market. Google enjoyed the default search status so far with Safari browser. As the Google’s focus in Mobile is changed dramatically and came up with its own OS and mobile devices, it is fast becoming a serious competitor for iPhone core business. Microsoft actively looking for all possible opportunities to win some ground in Mobile world trying to grab this and initiated discussions with Apple to make Bing as the default mobile search engine.

What this simply means is Microsoft Bing becomes the market leader in Mobile search. Stats say that Google enjoys 86% of mobile search whereas Bing is mere 11%. The key here is major chunk of Google search requests coming from iPhone. Microsoft already has Bing search iPhone app which has more futuristic search options such as location based with voice commands etc. On the other side, Google betting big on its Android platform and Google’s history clearly says the way they emerged as number one web search engine after disassociating their search engine with Yahoo. History repeats in Mobile?

Sreenivasa Rao Pilla Life at Aditi

One of the concern areas for any clients (tenants) in using any SaaS model application is “Data privacy”. “Data Sharing” option would really help the tenants, provided the application database design approach is fool-proof and build the confidence amongst the tenants.

SaaS (Software as a Service) is a model of software development whereby a provider licenses an application to customers (subscribers or tenants) for use as a service on demand. SaaS based applications are multi-tenancy not multi-instance application architecture.

“Data Storage”, “Data Synchronization” and “Database Maintenance” are three key focus areas from the deployment perspective. I came up with the following 3 database design approaches and optimized them to make the best out of each.

1.  Individual databases servers:
The best way to isolate the tenant’s data is to deploy the tenant data in separate database server. This approach is it is easy to extend the existing database to meet tenant’s customization requirements. Flip side of this approach is its high cost of hardware inventory, licensing cost per hardware, and maintenance. Few tenants’ who requires a high degree of data isolation (physical) and are willing to pay more can opt for this design approach.

2.  Shared database servers with Individual Schemas:
Tenant specific schemas would be created in the same database server and access rights permissions are enabled in such a way that a tenant can access only the resources (tables, stored procedures etc) in their specific schema. The key advantage of this approach is lower cost and support a virtually unlimited number of tenant’s databases. This approach will improve the performance of the application as we can work around a solution to effectively utilize the connection pooling. Even though the tenant’s databases are in different schemas in the same server, we can use the following technique to maximize the performance in DB connection. The following code is in C# (Microsoft .Net platform) and I am sure we can do the same with other languages as well.

1) objConnection.ConnectionString ="Data Source=MSSQL1;
InitialCatalog=FunnelDatabase; Integrated Security=true;";

2) objConnection.Open();

3) objConnection.ChangeDatabase(”Tenant1″);

4) objCommnad.execute ("storedprocedurename");

The point # 3 in the above code is important. An initial connection to the database server has been established to FunnelDatabase. However, before executing the stored procedure / SQL statement, line #3 is changing the target database to Tenant1. By doing so, we are still utilizing the initial connection string and hence using the same connection pool for all the target databases.

3. Same Database with Same Schema:
All tenants’ data resides in same schema and share the same set of tables. But, a tenant identifier can be added to the primary key (composite key). A key challenge in this approach is it is not customizable at tenant level and rigorous testing required to gain the tenant’s confidence for data security and data privacy. Barring the above concerns, this is the best among all three approaches in terms of cost and maintenance. Even in this approach, we can establish some degree of data isolation by using some of the advanced techniques such as “Partitioning methods“, which allow physical data separation of each tenant’s data across physical devices while providing simplification of maintenance due to shared table definitions.

Let us talk about deployment strategies with networking options in our next blog.

Sreenivasa Rao Pilla Life at Aditi

Mobile Application Architecture Series – Design Considerations

Mobile applications inherit various challenges which need to be considered while designing on any platform (Microsoft / Symbian / OS X etc). The following section tries to address various design guidelines for a mobile application development. Technology stack considerations would be the next in this series of blogs.

A mobile application will normally be a multi-layered application comprising user experience, business and data layers. When developing a mobile application, you may choose to develop a Thin-Client or Rich-Client. If you are building a rich client, the business and data layers will be located on the device itself. In Thin-Client, the business and data layers will be located on the server.

Design Considerations:

Follow these design guidelines to ensure that the application meets your requirements and performs efficiently in mobile world.

1)      Thin-Client or Rich-Client or RIA.  If your application requires local processing and must work in an occasionally connected scenario, consider designing a Smart (thin) client. But, a Rich-Client application will be more complex to install and maintain. If the application can depend on server processing and will always be fully connected, consider designing a Thin-Client. If your application has a rich user interface, only limited access to local resources, and portability to other platforms is required, then RIA would be a good choice (eg. ETrade).

2)      Device Types to Support: While choosing which device types to support, consider screen size, screen resolution (DPI), CPU performance characteristics, available memory and storage space (inbuilt & external) and Integrated Development Tool availability. On top of the above, we need to consider the User Requirements and Organizational Constraints / Guidelines. Any additional components such as GPS and Integrated Camera may influence your choice of application type and device type.

3)      Connectivity: The real time connectivity requirement between the mobile device and Gateway would highly influence the decision of whether to go for Thin-Client or Rich-Client or RIA. If an application requires an intermittent network connection, our design approach should properly handle caching, state management and data access mechanisms.

4)      UI design considerations: Mobile devices requires simple UI in order to work within the constraints imposed by the device hardware such as memory, battery life, different screen sizes and their orientations and network bandwidth.

5)      Layered Architecture: Depending on the application type, multiple layers may be located on the device. Use the concept of Layers to maximize the separation of concerns, and to improve reuse and maintainability for your mobile application. However, aim to achieve the smallest footprint on the device by simplifying your design compared to a desktop or web application.

6)      Security: Designing an effective authentication and authorization strategy is important for the security and reliability of your application. Mobile devices are usually designed to be single-user devices and normally lack basic user profile and security tracking beyond just a single password. Mobile applications can also be especially challenging due to connectivity interruptions.

7)      Caching: Use caching to improve the performance and responsiveness of your application, and to support operation when there is no network connection. Use caching to optimize reference data lookups, and to avoid network round trips. When deciding what data to cache, consider the limited resources of the device; you will have less memory available than a PC.

      Communication: Device communication includes wireless communication (over the air) and wired communication with a host PC, as well as more specialized communication such as Bluetooth or Infrared Data Association (IDA).  When communicating over the air, consider data security to protect sensitive data from theft or tampering.

9)      Performance Considerations:

a.       Design configurable options to allow the maximum use of device capabilities. Allow users to turn off features they do not require in order to save power.

b.      To optimize for device resource constraints, consider using lazy initialization.

c.       Optimize the application to use the minimum amount of memory. When memory is low, the system may release cached intermediate language (IL) code to reduce its own memory footprint, return to interpreted mode, and thus slow overall execution.

d.      Consider using programming shortcuts as opposed to following pure programming best practices that can inflate the code size and memory consumption. This decision should be a thoughtful one as it may contradict the design principles of OOPS and maintainability.

e.      Consider power consumption when using the device CPU, wireless communication, or screen while on battery power. We should balance power consumption with performance.

In my view, the above listed considerations are only a subset of complete list, but tried to address the key areas in it. One basic design approach for most of the mobile applications is “avoid BDUF”, Big Design Up Front, which recommends design evolving over time and avoid making a large design effort prematurely.

Sreenivasa Rao Pilla Architecture & Design, Mobile Architectures Architecture, Design Considerations, Mobile, Mobility