SOA is Not a Mobile Backend

The rise of mobile devices finally pushed the adoption of web services into the mainstream of application development. But years before this, companies used web services to build sophisticated service-oriented architectures for application development and integration. Some of the API management companies have even tried to adopt SOA systems for the new world of mobile devices. This article looks at some of the similarities and differences between SOA and mobile backend platforms.

The first distinction that comes to mind is that SOA is a huge undertaking in server-side software development. Companies that build SOA platforms end up creating large orchestrated palettes of web services that are standardized, reusable, granular, abstract, stateless, discoverable, and loosely coupled. This is very different than a mobile backend, which is designed to automatically provide all of the services you need without server-side software development.

So mobile backends are designed to provide functionality right out of the box, and SOA systems require lots of work to build the software. But if they are so different, how do both technologies support service-based applications? Are the new mobile applications just simpler than older applications built on top of SOA? Or does SOA include a bunch of stuff that really could be delivered as more of a standardized backend?

The answer is that smart devices have moved presentation capabilities and business logic to the client. There is less need for these capabilities on the server side. When you remove the “smarts” from SOA this opens up the opportunity for a more standardized backend platform that handles data access, external service proxy, and other mobile infrastructure needs. The diagram shown here illustrates the shift from server to client.

The shift to client-side logic also changes security considerations. When the business logic lives next to the database, they can trust each other. But a client device might be malicious. So mobile backends need to provide role-based access controls, user management, single sign-on and other security mechanisms to protect data sources and other server-side assets.

There is another difference. SOA was often used with an enterprise bus to provide services across a network. In some cases SOA enabled partner integration, in other cases services were needed for business applications running on desktop browsers. But mobile backends and Internet of Things (IoT) systems must support thousands or millions of simultaneously connected devices. Many of the complex services that SOA systems provide cannot be reliably delivered in the transactional world of mobile applications. 

Mobile backends are optimized for multi-process Infrastructure as a Service (IaaS) cloud delivery for exactly this reason. Platform as a Service (PaaS) systems can automatically scale backend resources. Big data is another technology well suited for massive transaction volumes. Docker-based applications that use micro-services are a future direction for highly scalable mobile backends as well. The older generation of SOA systems that run on application servers are not well suited for this new world.

And, in fact, the runtime characteristics of SOA web services are also somewhat incompatible with mobile applications. Modern developers need RESTful interfaces that work with JSON, the compact native object format for JavaScript. This supports HTML5, hybrid mobile application, and native iOS and Android development. Older systems using Simple Object Access Protocol (SOAP) and XML may require translation. 

REST APIs are very efficient and work better on mobile networks. You just specify a URL and you get the JSON data. SOAP transactions depend on exchanging complex documents that must be carefully constructed and properly interpreted.

Another much-heralded but little-used aspect of SOA is service “discovery” using WSDL, the Web Services Description Language. The over-engineering of SOAP and WSDL by the W3C was a major reason for their decline, but the concept of automated service discovery and use never really worked, either. 

The API Economy has a much simpler answer for this problem: developer marketplaces where RESTful services can be quickly found, and interactive service documentation systems like Swagger and RAML. Of course these methods require human intervention, but so did WSDL in most circumstances.

All that having been said, I believe many of the principles behind SOA are important concepts that the new world of mobile backend platforms should incorporate. Many traditional SOA value propositions can be reformulated from a client-side perspective to address the needs of modern developers.

First let’s talk about API complexity. In short, with each new mobile project, there is a tendency to build more and more RESTful APIs. Over time, the server-side becomes increasingly complex, and this reduces portability, scalability, efficiency, and security. Building all of these APIs also slows down the development process and increases cost. By applying the SOA inspired concept of building “reusable” APIs, a company can reduce the complexity of their backend infrastructure.

The modern enterprise needs hundreds or even thousands of mobile applications. First they identify the backend data sources that need to be mobilized, and then they create a reusable and general purpose REST API platform. After that, developers can build any type of client application for any device using a “standard” set of services. They don’t have to learn new APIs for each new project. The front-end application becomes “loosely coupled” to the backend infrastructure, another valuable concept taken from SOA.

Backend services should also be “composable” and “granular.” Each service is a little building block that can be used to access various data sources and other capabilities. A wide variety of client applications can be created simply by mixing and matching different services and URL parameters. Care should be taken that the services are not too granular, because repeated calls to the backend can hurt performance. 

Hitting upon the right abstractions for composable, granular, reusable, and loosely coupled web services can be a challenge. At DreamFactory, we built and rebuilt our open source mobile backend many times before hitting upon the right recipe for RESTful services that could support general-purpose application development. But our early experience working with SOAP-based services on SOA platforms over a decade ago provided a lot of guidance along the way.