Service-oriented architecture (SOA) is a software design style where services are well defined, independently developed, self-contained, and do not depend on the context or state of other services to succeed. Recently, we had the opportunity to attend a conference session discussing SOA at the Big Android BBQ this past October. This session, presented by Lorne Liechty of Bypass Mobile, discussed the benefits and challenges of using SOA to produce a multiple APK distribution within an Android application.
The use of SOA in enterprise Android applications makes individual components highly scalable and enables rapid development of diverse features across multiple development teams. These individual components make it possible to distribute multiple apps to create a modular suite. This is a recap of that session and some thoughts surrounding service-oriented architecture and its usage.
Why Use Service-Oriented Architecture?
Service-oriented architectures are useful for immediately separating the concerns of an application. Instead of having a monolithic approach where all aspects of an application reside in the same code base, a service-oriented approach separates out code to reflect the single-responsibility principle where code is grouped per its desired tasks. For instance, an account authentication service can be separated from an ecommerce browsing service, and each of these services can be developed, tested, and maintained independently.
A further benefit to service-oriented architectures is the reduction of code duplication and ease of reuse. If another service needs to be developed that requires account authentication, then the existing account authentication service can be leveraged without needing to copy or re-implement the code. Bug fixes in a service-oriented architecture will also be applied to all applications that utilize a service, rather than recompiling all services.
Figure 1 – Monolithic architectures (left) will need to import and reuse the same module across different applications, whereas service-oriented architectures (right) can reuse the same module/service across different applications.
Adding Service Oriented Architecture to Your App
Many Android architectures are monolithic in nature with much of the business logic occurring in the activities and fragments of the application. Most of this excess code handles the implementation of different services (i.e., authentication, REST, hardware, etc.) that bloat the application’s codebase. Furthermore, many of these services can be reused in other applications. By using service-oriented architecture, developers can abide by the DRY (don’t repeat yourself) principle. It is important to isolate the areas of an application that are appropriate for separate services.
The following are example of application features that can be separated into their own service module and reused across multiple applications:
Authentication:
Authentication is required for most applications dealing with user data in order to verify and identify the user or device.
By creating a service module that implements abstract authentication functionality, a company may use this service as a product both internally and externally for applications requiring authentication. Any application using this service would be able to customize this abstract functionality to make their authentication functionality different from one application to another while maintaining the same basic implementation.
REST:
REST services are required for most applications communicating over a network to retrieve data for their application. These services tend to make up the bulk of excess code in most Android applications.
By separating these services into their own module it will allow them to be used in multiple applications. For example, a company could develop a payment service API that allows applications to implement the same payment service across multiple applications. This service would then be localized and updated from the company that provides it.
Hardware:
Hardware services are required for applications communicating with a specific piece of hardware to complete an action. For example, many applications use a card swipe to take payments, authenticate users, and clock employee time.
A company that provides these pieces of hardware can also provide a swipe API that allows users to implement functionality as a result of a card swipe. That API would be the baseline for an application’s swipe functionality and could be customized to meet any future needs.
Next, the main point of these services and service-oriented architecture as a whole is interoperability.
A more traditional service-oriented approach would be to have multiple service-specific APKs that create intent services or bound services. An intent-based service can run in the background and listen to application-specific intents that will run the service’s code asynchronously. A bound service creates a more robust interface that other apps can interact with, but often is limited to availability when the app is running. Both types of services can provide an SOA approach for Android cross-app interactions.
Difficulties With Service-Oriented Architectures
The overhead of developing service-oriented architectures may sometimes outweigh the benefits of separating each module into its own service. Consider that each service will need to be deployed and maintained separately, require a mechanism for communicating with other services, and may act as a single point of failure—bringing down multiple applications at once. Versioning of a service is also necessary to ensure that some applications that take advantage of the architecture can be updated independently of other applications.
Inter-service communication can also greatly increase the time-to-respond for an application. If the inter-service latency is 100ms and five separate services are called in an application, then every call to an application has a built-in half-second delay to respond. Performance and load testing of a service-oriented architecture is therefore crucial, and the infrastructure to support SOA may be different that a traditional monolithic server.
Final Thoughts
Android applications can benefit from an SOA approach that has previously existed only on traditional servers. By separating application components to have singular responsibilities, developers can either provide a monolithic, library-based approach to Android development or explore a more service-oriented approach with intents or bound services.
The Android ecosystem is constantly evolving, and we’d love to help you explore different architectures to solve your challenges.
Contact Us
Ready to achieve your vision? We're here to help.
We'd love to start a conversation. Fill out the form and we'll connect you with the right person.
Searching for a new career?
View job openings
