Best-of-breed mobile applications require careful design of the services layer. Just because an existing web app works well on a fat client doesn’t mean it will work well running on your phone, regardless of the number of mobile client optimizations you may have added to your code.
Mobile and Desktop are Not Always Interchangeable
The reason for these differences is simple: Not all services are created equally. Architects and developers have a number of choices to make when designing services. Based on the choices you make, application behavior and capabilities can be quite different.
Your services architecture is really the foundation of your application; like a house, it is difficult and expensive to change once you’ve put it in place. In terms of application architecture, there are a number of things you can do that will optimize mobile application performance and minimize application maintenance costs over time.
The Path to a Strong Services Layer
The first step is to build a single application that covers all channels needing access. Don’t create a separate version that just supports mobile devices. What I’m describing here is commonly known as omni-channel vs. multi-channel. If you’re planning to extend an existing application to provide mobile support, this will require some re-architecting of your current application, but it will save you money in the long run.
The next step is to look at the level of granularity that your services target. Too course-grained and you’ll end up with page sizes and load times that will choke your mobile devices and hurt performance. Too fine-grained and you’ll be generating too many service calls. We’re aiming for the sweet spot, where average page loads are well under 1 MB in size and the number of service calls is reasonable. This will give you good application performance with manageable messaging overhead.
Another benefit of using fine-grained services is that it makes it a lot easier to add third-party services, or make incremental changes to existing functionality. A given service can be modified, added, or deleted, with minimal impact to the rest of the application. Because of the flexibility that an atomic services architecture provides, companies who are moving to agile development practices will also find it much easier to implement leading edge techniques for continuous development and deployment.
One of the consequences of creating more fine-grained services is that you also generate a lot more APIs to organize and manage. In addition to the proliferation of internal APIs, you may find yourself using more external APIs that embed third-party functionality. For example, you might use the Google Maps API for location services, a credit card provider API for credit card authorizations, or Twilio APIs for notifications. As your API portfolio grows, you’ll need to provide more oversight and governance.
The Changing Face of the Application Layer
In a traditional three-tier application, the application layer is very monolithic, embedding capabilities for client management, data and protocol transformation, and other service delivery functions in addition to core business logic. In a four-tier mobile architecture, service delivery is decoupled from the business logic, making it easier and faster to make changes to business functionality.
The application layer is a little tricky because it has more to do with how services interact with each other than the design of any specific service. For example, in a mobile commerce app, the data that’s sent to the phone may depend on how the user is interacting with the application. Dynamic service composition based on event processing rules, or content-based routing, must be able to fire off secondary business processes or service interactions that are relevant to the user experience at that moment in time.
And finally, use REST services wherever you can. REST services are a lot simpler than SOAP and typically use JSON for data payloads instead of XML. This eliminates XML parsing requirements on the device side and improves performance. Even if you’re accessing a backend SOAP service, consider mapping REST calls to SOAP operations so that your services layer uses a consistent interface style.
This is not an all-inclusive list, but if you get these things right in you services architecture, you should be in pretty good shape.