Essential Guide

Browse Sections


This content is part of the Essential Guide: Guide to enterprise mobile app development and SOA
Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Mobile impact on SOA offers apps big gains

Mobile broadband has a big impact on how people access and use online resources. Tom Nolle discusses how mobile services on SOA affect apps today.

Tom Nolle

Tom Nolle, president of 
CIMI Corp.

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 af­fect 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 map­ping 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 represen­tational 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 re­member what was done before. This makes it simple to scale RESTful ser­vices 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 require­ment 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-format­ted 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-stan­dard 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 fea­tures 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), combin­ing 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 ap­plication 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 alarm­ing charges without knowing why. An agent process is a user-activated soft­ware component that runs in the cloud and is accessed when the user makes a request. The process then performs the data gathering and processing in­side 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 en­gine, 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.

Dig Deeper on Enterprise application integration

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.