As mobility has exploded onto the list of of top IT priorities over the past few years, many IT shops are realizing that one of the first steps in creating mobile apps that make use of data is figuring out how to properly expose that data via web services. Beyond the standard technical recommendations – there are some common architectural design principles to be aware of when designing and building services – whether they’re internal, enterprise services or public-facing mobile web services.
These principles are well documented throughout the internet, but I found it difficult to find a simple, concise, easily digestible format that wasn’t quickly treading into pie-in-the-sky architecture speak. Careful consideration should be given to these principles early in the design process in order to mitigate the downstream impact of poor architectural decisions. Most of these principles are also beneficial to other areas of object-oriented software development (i.e. loose coupling) – however, the below principles will become readily apparent and relevant when building services.
The six principles are:
Several (autonomy, statelessness) of the six principles also assist in the creation of loosely coupled services. A loosely coupled service requires limited knowledge of the definition or inner workings of other components relied upon by the service. The benefit of loose coupling is the flexibility and agility gained by being able to change the inner workings of a service as needed, without having to make related changes to clients or other components relying upon the service. There are a variety of ways in which services can be tightly coupled – for example: contracts, security, technology, and statefulness.
Coupling via the service contract can occur when the contracts are built against existing logic from back-end systems (i.e. using ORM-generated classes that contain every single database field), which can hinder the evolution of a contract as it has not been designed independently of the underlying logic. Coupling via security or technology can occur when a service is based upon security or communication protocols that limit the adoption of the service – for example, a service built upon an outdated technology (i.e. CORBA or .NET Remoting), or a rarely-used security protocol which may not work across all devices. Coupling via state can occur when service operations must be called in a specific order, coupling the service with the order of operations and session state that must be maintained on the server. Coupling against state can also have a negative impact – for example, a step cannot be added into the middle of a process without updating all service clients.
Service autonomy is a design principle that allows for services to operate more reliably by having maximum control over their execution environment and relying as little as possible on the availability of external resources for which they have no control. Autonomy can be increased by running services on dedicated hardware (reducing dependence on other systems running on the same hardware) or by storing cached copies of data, thus reducing dependence on external databases. Not always possible in every scenario, but good to keep in mind.
Requiring that service operations be called in a specific order increases coupling via an implicit contract – meaning that the order in which the operations should be called is not known and documented by the service itself, but rather must be documented via outside knowledge. Reducing state within services allows for services to be more scalable, as the amount of resources consumed by the service to manage and track state information does not increase with the number of consumers. The most common way to reduce service state is to manage all state at the consumption level – forcing the client to keep track of its own state.
Service consumers should rely only upon a service’s contract to invoke and interact with a service and those interactions should be based solely on the service’s explicit contracts, those which are defined by the service itself, e.g. via a WSDL document – rather than any implicit contracts, for example – external documentation.
Several best practices regarding contracts include:
Service composability is a design principle which encourages services to be designed in a way that they can be consumed by multiple external systems. This promotes the reusability and agility within a service-oriented environment, as it allows new systems to be built by re-using existing services. Composability is further enabled by several of the other design principles including Autonomy (increases reliability of the service such that it can be used in other systems) and Statelessness (allows the services to be used in conjunction with other services without regard for state).
Discoverability is a design principle that encourages services to be discovered more easily by adding metadata about how the service should be invoked and interacted with, and storing that metadata in a central repository if possible. By making the services more easily discoverable and cataloging the related information, the services are inherently more interoperable and can be re-used more easily. The core consideration for this principle is that the information catalogued for the services needs to be both consistent and meaningful. The information recorded about the services should be accessible by both technical and non-technical users, allowing anyone to evaluate the capabilities of the service and whether or not it should be used.
While not all of the services design principles can be followed to the letter in every real-world services implementation, the guidelines can generally be applied regardless of the scenario. The following recommendations should be observed in regards to building well-designed services.
When developing mobile applications, there are a number of key challenges where architecture and design are fundamentally different from that of a typical enterprise application. Careful consideration should be given to these mobile architecture issues early in the development process in order to mitigate the downstream impact of poor architectural decisions. While some of these best practices also make sense for the development of non-mobile applications, many will become more readily apparent when developing on a mobile platform. The five most important areas for consideration, which are detailed throughout this document, include: performance, usability, data access, security, and connectivity.
While more readily apparently in the previous years of mobile development, the computing power available on mobile devices still lags behind desktop and server counterparts and will continue to do so for the foreseeable future due to smaller device footprints and resource constraints. Even the most recent devices still boast only about one third to one half of the computing resources (CPU, RAM) of a low end desktop computer. Further, the quality of data connections available on a mobile device is often highly variable based on signal strength and is far inferior to broadband Internet access in most cases.
Often during rapid application development, performance considerations are ignored until the end of the project and optimized only when necessary. In mobile development, more consideration to performance constraints of the mobile device may need to be given up front in the design process. Each platform has different code-level best practices for performance optimization depending upon the programming language and frameworks available on the platform. Some best practices, such as judicious usage of memory and limits on the number of unnecessary objects created, however, can be applied across all platforms.
Care should especially be given to architectural decisions that can limit performance and are also difficult to change later in the development cycle, such as the design of web service APIs and data formats. General best practices for the design of web service APIs for use in mobile development could be summed up as:
These considerations stem mostly from the limited bandwidth available to mobile devices. If possible, APIs used by a mobile application should be designed to retrieve only the most relevant and useful information – excluding any extra data that is not used by the application. When designing APIs to communicate with mobile applications, one recommendation is to use a lightweight data format like JSON instead of more verbose format such as XML in order to make the best use of limited bandwidth available to mobile devices. The use of a lightweight format like JSON will conserve bandwidth, will allow results to be retrieved more quickly, and also will generally enable faster deserialization of the data as it arrives on the mobile client.
Another important performance consideration on a mobile device is battery life. If an application is constantly polling a web service for updates or continually processing data in the background, the battery will be drained much more quickly. If architecturally feasible (and if the push notification capabilities exist on the mobile platform), the use of push notifications for providing data updates is recommended over periodic polling. Push notification capabilities currently exist on the iPhone, Android, and Windows Phone 7 platforms. If an application needs to perform large amounts of data processing or analysis, consider uploading the necessary data to a server-side platform to perform the CPU-intensive processing and then return the results to the device to avoid draining the battery and to provide a more-responsive user experience.
At the end of the day, usability is one of the key factors that will truly make or break user acceptance of an application. Each of the major mobile platform software vendors (Microsoft, Google, Apple) have released user-experience specifications and guidelines specific to their own platforms in an attempt to foster a consistent look and feel across all applications on their platforms – and if the guidelines are enforced by the vendor and followed by developers, then the payoff is absolutely realized. The user experience across applications on most of the major platforms is seamless – for example, on the more stringent iPhone and Windows Phone 7 platforms, the navigation of menus and the look and feel of most applications (down to the fonts and color schemes) are almost identical. This allows users to learn quickly how to use a new application and instead focus on performing the task at hand, rather than “switching gears” between disparate experiences or puzzling over how to interact with a new application. Below are links to the user experience guidelines for each of the major platforms:
While each platform may have specific user interface (UI) guidelines, the challenges of mobile application usability are ubiquitous and many best practices can be applied across all platforms. Following are a few of the most important usability considerations.
One commonality between the most modern mobile platforms (iPhone, Android, Windows Phone 7) is that none of them offer any capability to connect directly to a database – for good reason. The current mobile architecture paradigm simply doesn’t support this scenario for modern database platforms in their current state. Given that most mobile applications communicate over the public Internet, access to a database would require exposing that database publicly – and in this age, no sane IT or database administrator would publicly expose an instance of Oracle, SQL Server, or MySQL outside the firewall without measures like a VPN or IP restrictions in place. While VPNs are becoming more available on modern mobile platforms, the complexities around cost, bandwidth, and end-user configuration simply don’t make business sense when compared with fronting a database with a more secure web service front-end.
Rather than attempting to provide support for database client connectivity, the current paradigm for data access from mobile applications is based around web services. For the example scenario of extending a common two-tier enterprise application onto a mobile platform, usually a web services layer would first have to be created that would exist in front of the database or APIs of the enterprise application. In the design of a web services layer for a mobile application, logic around authentication, authorization, validation, and business rules should all be executed on the server-side web services of the extended application. As the web services are now exposed publicly for use by any properly authenticated user of your application, the validity of the data and the user’s right to call the web service cannot be trusted without first performing additional server-side checks. Logic for validation and authorization can be duplicated on the mobile client side of the application to provide a more responsive user experience, but the user’s actions should be checked again on the server side after the data is passed to the web service.
The architecture diagram at right below depicts how an enterprise application could be extended onto a mobile platform by wrapping either the application’s APIs or database with a business layer that performs additional processing for validation and security. Note that if validation or authorization is built into the enterprise application’s APIs or data access mechanism, then it is not necessary to re-implement this functionality within the web services layer.
As previously mentioned, data access on mobile platforms generally requires some form of Internet-facing service or data access point that can be communicated with via a mobile device. Database servers and platforms in their current state are not good candidates for public exposure without additional layers of security that are generally not feasible or cost effective on mobile devices. Web servers are generally more hardened to attack and, thus, web services are an excellent candidate for exposure outside the firewall to mobile devices over the Internet. But what about securing these web services?
In most cases, the use of a web service API first requires authentication to ensure that the caller of the web services is who they say they are. Usually, web service API security will use a form of token-based authentication – this could be something like OAuth or as simple as sessions built into any modern server-side framework, such as ASP.NET or Ruby on Rails. In the general workflow of token based authentication, the web service caller sends a username and password and then receives a unique token back after his/her identity has been verified by the authentication service (e.g. LDAP). The token is then passed back to the web service on all subsequent requests and can be used on the server side to determine the identity of the user. Depending upon the security constraints of the application, the token generally expires after a certain period of inactivity. Regardless of the technology used to accomplish the token based authentication, all communication between the mobile client and the web server should be performed over an SSL-secured connection in order to prevent the token from being captured via packet sniffing on a wireless connection or any other “man-in-the-middle” attack. If the token were to be compromised by a third party, the third party would then be able to imitate the identity of the actual application user and would be able to make malicious requests, if inclined.
Another security issue inherent to mobile platforms is the security of data that exists locally on the device itself. Obviously, any mobile device can be compromised much easier than a server residing within a secure data center. If possible, confidential data should not be stored on the mobile device itself and should be stored instead on a back-end server and downloaded to the device when necessary. If for architectural reasons confidential data must be stored on the device, then measures should be taken to encrypt the data with a key that is not stored on the device, if possible. Fortunately, mobile platform vendors are providing more and more support for automatically encrypted disk storage, which makes implementation of secure data storage on the device much easier. One further consideration for mobile data storage security is that highly confidential data, such as private health information (PHI), should not be stored on a mobile device under any circumstances, encrypted or otherwise.
The final major architecture consideration for mobile applications is connectivity. It can no longer be assumed that the application being built will have access to an “always-on” high-speed Internet connection. In the wild, mobile devices will frequently switch between different types of connections (e.g. Edge, 3G, or WiFi) with wildly varying speeds and will often have no data connection. Often, the implementation of offline access for a mobile application simply doesn’t make sense business-wise, architecturally – perhaps the application must have access to only the most relevant and up-to-date data (e.g., traffic conditions), or when data is persisted it must be immediately validated and processed (e.g., stock trades). For most business applications, however, there are use cases for which offline access is absolutely necessary in order to maintain the end user’s productivity. One simple way to design offline access and data synchronization involves the creation of two basic components within the mobile application – a caching mechanism and a queuing mechanism.
The caching component handles offline access for data that would normally be retrieved as needed from a server-side API. The caching component can be designed to periodically (in a background thread) retrieve larger data sets that are potentially relevant to the needs of the end user, or it can be designed to only keep copies of any data previously retrieved from server. Data stored in the cache on the device should generally expire after a certain time period has passed in which the data is no longer useful or relevant. Another feature that can be designed into the caching feature is some level of intelligence related to the current type of connection on the device. For instance, if the cache is designed to periodically download large data sets, then perhaps it will only do so when the device is connected to WiFi in order to conserve bandwidth when connected to slower connection types. The implementation of a caching component can also provide the benefit of a more responsive user experience, as data can then be retrieved from the local cache rather than round-tripping to a server over a slow connection.
The queuing component handles the persistence of data to the back-end services. The queuing component can be designed to sit in front of the web service API client within the mobile application and check to see whether or not a connection is available when attempting to call the web services. If a data connection is unavailable, then the update is placed into a first-in, first-out queue in memory. The queue should then periodically check (in a background thread) to see if a connection is available and then send all data updates to the back-end services in the order in which they were received. The queue should also be designed with business logic around the reconciliation of data conflicts. For example, if a data update is sent to the server and is determined to be out of date or invalid, then the end user should be notified of the error and given a mechanism to correct or discard the update. Another feature that should be designed into the queue is the persistence of the queue to local data storage on the device; if the application is closed or interrupted, then the queued updates will be kept safe until the next time the application is used. Below is a depiction of a mobile architecture using local caching and queuing services to provide offline data access and data synchronization.
As you can see, when designing an application that will be living “in the wild”, outside the corporate firewall, there are numerous challenges that simply don’t exist when building enterprise applications that run in well-known conditions, safe and secure within a corporate datacenter or colocation facility. Performance and usability will make or break the usage and acceptance of any mobile application. Now that users are used to the snappy and responsive interfaces of their modern iPhone, Android, and Windows Phone platforms, they will loathe using any application with a sluggish, unusable interface. Accessing data on a mobile device can be a whole new ball game for enterprise developers who haven’t worked with web services or have spent years writing and maintaining classic two-tier or mainframe-based applications. Security is rarely a concern for developers writing applications that are safely tucked away behind a corporate firewall and intrusion-protection systems, but when exposing APIs with access to business-critical information to the public Internet, there is no way that security-through-obscurity will suffice any longer. Connectivity is especially challenging to design around on a mobile device that will commonly have a very slow connection or no connection at all – for an enterprise application running in a data center, on the other hand, it can usually be assumed there is a redundant, high-availability, high-bandwidth Internet connection available.
In summary, while it can be challenging, there are well known solutions for each of the previously mentioned issues. And though each mobile platform will have its own specific best practices for each area, many of the best practices are standard across all mobile platforms, regardless of the technology used.
West Monroe Partners is a full-service provider of business and technology solutions. Our consulting professionals are experienced in developing enterprise and consumer mobile applications on the Apple iOS, Android, and Windows Phone 7 platforms. Please contact us for more information on how our mobile application development team can work with you to ensure that your mobile applications follow the appropriate best practices. Click here to read more about West Monroe Partners’ Mobile Application Solutions.
One thing that any web developer worth their salt should know is the basics of search engine optimization (SEO). Much of SEO comes down to basic code-level best practices, and it isn’t terribly difficult to simply bake SEO into your development process when working on public facing web applications. However, keep in mind that SEO will always be an evolving, fuzzy science, changing on the whim of the indexing strategies of major search engines. Immediate results are rare, and a long term process should be in place to truly understand the benefit (or detriment) incurred.
I break the concept of SEO down into a few categories that I’ll explain further below…
These ‘Content / Internal’ best practices are things that a developer or content creator can bake in during the site development process. Only a few of these items will make a difference on their own, but as a whole can make an enormous impact. These basic factors should lay the foundation for any SEO strategy. However, these internal factors absolutely cannot be the only part of your SEO strategy. Here are a few of the most important ones…
Strategic SEO includes all of the factors external to your website that can affect your search engine rankings. The number one external factor is getting ‘backlinks’ to your content, this is what made Google so ridiculously powerful and accurate – and their rankings are still very much based on the number, diversity, and quality of links to to your site.
Backlinking can be explained with this anecdote: Several years ago you could search for ‘Miserable Failure’ on Google and the number one result was the White House biography page for George Bush. This was due to a simple viral campaign to get people to put links on their websites, comments, blog posts, etc. linking to the biography page with the anchor text ‘Miserable Failure’. That’s how backlinks work. The more external, inbound links to your site, the more ‘authoritative’ your site appears to be in the eyes of major search engines.
But how can you get these backlinks? A few examples…
As mentioned previously, part of SEO includes a process testing out your SEO changes and tracking their effectiveness over time. A variety of free and paid tools are available to assist you in analyzing your search rankings, search terms, and keyword effectiveness. Below I’ve listed a few tools that can help.
There is much more to search engine optimization than can be written up in a single blog post (see also: thousands of blogs dedicated purely to the subject). However, I hope this quick guide to the basics will give you the tools necessary to implement numerous high impact SEO quick wins for a client or personal web site. For web developers, the factors listed above should be kept in mind whenever developing customer-facing websites that could benefit from enhanced search results and search rankings. Most of the ‘content / internal’ best practices can be easily baked into the development process of almost any e-commerce or content management system implementation project.
The impact of performance is much more readily apparent in .NET Compact Framework applications. The mobile devices commonly have a CPU that is 10 times slower than your desktop CPU, and possibly up to 100 times less RAM than a desktop or server. In Agile or XP development, the mantra is often to ignore performance considerations until necessary – I don’t think you can apply that to .NET CF development or it will really bite you in the end. You don’t have to go nuts and optimize everything up front, but there are some very important things to keep in mind when developing a Windows Mobile application…
Many of the standard .NET Framework performance best practices can become apparent very quickly including…
However, the .NET Compact Framework is different than the full framework in many ways, leading to a slew of .NET CF specific performance considerations…
I’m starting up a short Windows Mobile project again, so I thought it would be a good time to collect some of my best practices for .NET Compact Framework development and post them. I’m going to break them down into two sections - usability, and performance best practices (in another post).
Microsoft has put together a very specific set of guidelines for Windows Mobile usability – the point of this is to get a consistent set of look and feel and application experiences on their platform. Apple has the same sort of guidelines for iPhone development and it really pays off – most applications have the same consistent look and feel and excellent usability. Of course, many of these usability guidelines are relevant across many development platforms, but there are some special considerations for mobile development.
Usability is a challenge in mobile development. Some of the main concerns include…
Here are some of the most important usability guidelines that Microsoft has set forth…