The app revolution spawned by the iPhone and other smart devices has proved that mobile broadband has a profound impact on how people access and use online resources. So it's logical to ask how mobile broadband will affect application development in general and service-oriented architectures (SOAs) in particular.
The reason to focus on SOA as a target of mobile impact is this: Mobile users are highly compartmentalized in their online usage. While traditional-computer users go to a Web browser to find something, mobile users want to use an app. Structurally, such an app is a link between an on-screen icon, some optional local processing and a URL. In many cases there's a 1:1 mapping between apps and online services, and it's this kind of componentization of services that SOA targets.
What about RESTful Web services?
On the surface, it looks like all mobile apps promote SOA, but that's too simplistic. The Internet revolution in general, and mobile Internet apps in particular, have created a model of a "Web service" that's based on representational state transfer (REST), the so-called RESTful interface. REST creates an "as a Service" model that's similar to SOA in some ways and very different in others.
RESTful interfaces represent stateless event/response processes. That means each event is processed in its own context; the service doesn't remember what was done before. This makes it simple to scale RESTful services to the Internet level, but tasks that involve multiple services threaded into a logical sequence have to be orchestrated by something else --usually the device making the request. An HTML page is the script that invokes RESTful interfaces. In SOA, most practitioners would argue that the stateless requirement is less rigorous, and SOA also has an implied orchestration model in the service bus or workflow engine -- a message exchange that links SOA components to applications by threading messages from one to the other in a structured way.
RESTful interfaces are also simpler. In many cases, they're a simple HTTP GET and POST exchange of some minimal data structure or an XML-formatted payload. Security, if provided, is offered through HTTPS. With SOA, an XML-based Web Services Description Language (WSDL), the Simple Object Access Protocol (SOAP) and a series of supporting standards (the "WS-standards") provide for everything from intermediate handling to data security and user identity management. Few Web developers have ever worked with WS-standard interfaces at all, and most mobile device platforms don't offer complete support for them.
Making secure apps
It seems that mobile app trends not only favor RESTful interfaces, but also that mobility could drive the market in a RESTful direction. That may happen, but there are two countertrends pushing developers the other way. The first is the increased demand for reliable and secure apps; the second is the move toward "agent processes."
As technologies such as NFC credit management and TV Everywhere move mobile services to other services that require identity and rights validation, many developers find they're inventing much of the SOA/WS-standards features to augment RESTful interfaces. Not only is this wasteful, but it creates nonstandard approaches that limit the value of componentization, which is what's driving REST and SOA. At the same time, progress is being made to simplify the often bewildering SOA standards (WSDL Version 2.0), combining them with RESTful interfaces at the low end of functional requirements. Yet there's still a huge lack of capability, and many developers report that tools for WSDL 2.0 are sparse and primitive by comparison.
This is why the "agent process" trend is so important: Rather than requiring that SOA and REST come together, it separates them in the application structure. The basic principle is that as mobile tasks become more complex, it's impractical to use a device to collect and process the multiple RESTful services that might coalesce to create an app. Not only is the data-handling a burden for a small device with limited storage or CPU resources, the mobile connection is also typically usage-priced, so the user could see alarming charges without knowing why. An agent process is a user-activated software component that runs in the cloud and is accessed when the user makes a request. The process then performs the data gathering and processing inside the cloud and returns the result to the mobile device.
Orchestration of services
This structure separates the service orchestration that creates the application from the device, turning device-handling of multiple RESTful services into what is essentially an orchestration or workflow. Thus, a RESTful request to the agent process could be orchestrated using standard SOA, SOAP or WS interfaces and workflow engines, and the result is returned to the device as a RESTful response. Such a structure would stress the definition of REST, since some would argue that the agent process is now stateful, but the handling would be little different from that of a Web front end to an application engine, a model used by nearly all enterprises today.
The stateless vs. SOA debate raises the question of scalability, which is what stimulated RESTful development in the first place. The Web proves that RESTful logic that does client-hosted threading of multiple interfaces into an app can scale. Mobile services stress that model for cost and performance reasons. The question is whether SOA or REST will find a balance in the mobile era.
About the author
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.
Follow us on Twitter at @SearchSOA.
This was first published in April 2013