SOA is Not a Mobile Backend

The rise of mobile devices finally pushed the adoption of RESTful 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 enterprise service bus (ESB) and API management vendors have even tried to adapt SOA systems to the brave new world of mobile devices—with limited effectiveness. I'd like to examine some of the similarities and differences between SOA and mobile backend integration platforms.

What’s New is Old Again

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 with very little to no server-side software development. As Gartner noted, "Infrastructure components, such as an enterprise serice bus, are often poorly suited for mobile app usage." *

So mobile backends are designed to provide RESTful services 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 below 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 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.

Transactional Mobile

There is another difference. SOA was often used with an ESB to provide services across a network. In some cases, SOA enabled partner integration. In other cases, services were needed for a relatively small nmber of business applications running on desktop browsers. But mobile backends and Internet of Things (IoT) systems must support thousands or millions of simultaneously connected devices.

The client for SOA is usually a server capable of digesting complex XML documents. The client for mobile services is usually a human on a cell phone. This is why mobile services are small in size and need to be delivered quickly. The complex services that SOA systems provide don’t fit the transactional world of mobile applications.

Mobile backends are optimized for multi-process Infrastructure as a Service (IaaS) cloud delivery to maximize performance. 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 microservices are a future direction for highly scalable mobile backends as well. Traditional SOA systems that run on application servers are not well-suited for this new world.

Other 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.

But Wait, I Love You

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

First, let’s talk about API complexity. In short, with each new mobile project, there is a tendency to build more and more specialized 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. According to multiple analyst firms, 50%-70% of the costs of a mobile development project are associated with backend integration. By applying the SOA-inspired concept of building “reusable” APIs, a company can slash mobile development time and costs, reduce the complexity of their backend infrastructure, and improve data security with hardened APIs.

The modern enterprise may need to develop dozens or even hundreds of mobile applications in the coming years. The smartest mobile appilcation integration strategy is to start by identifying the backend data sources that need to be mobilized and then they create a reusable and general purpose REST API platform to securely expose the data. After that, developers can build any type of client application for any device using a “standard” set of RESTful web 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", basically microservices for application integration. 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, tough. Repeated calls to the backend can hurt performance.

Back of the Backend

Hitting upon the right abstractions for composable, granular, reusable, and loosely coupled RESTful web services can be challenging. At DreamFactory, we built and rebuilt backend services over many years before hitting upon the right recipe for RESTful web services that could support general-purpose application development. And that experience is what led us to build DreamFactory's open source RESTful backend integration platform for everyone to use. But our early experience working with SOAP-based services on SOA platforms over a decade ago provided a lot of guidance along the way.

* "Enable Your Digital Business With a Mobile App Integration Architecture" ~ Gartner 2014