My last post discussed the Service Based Internet and its importance. For this post, I wanted to focus on the Core Components of the Service Based Internet.
Challenges of Service Based Architectures
There are considerable benefits to having a loosely coupled, widely distributed system. In decoupling the various components of our systems, however, we have to contend with several challenges associated with loosely coupled systems. Namely; system availability, reliability, security and interoperability. Before the rise of Mobile, PaaS and IaaS, we built our applications in a controlled, self-contained environment. It was no problem to perform direct database queries when the database was one rack over in our datacenter. We had direct control over the access, performance, reliability and availability of the database. Likewise, even if we did choose to develop a three-tier application, all three tiers were in the same ecosystem. There was no need to account for synchrony because we had tight coupling of our tiers at the transport layer and direct control over the availability of all components of our application.
Today, however, our data may live in one or more clouds while our business logic resides in a remote BPM system or an on-premise system of record. Even more challenging, our presentation layer may reside on a remote web server or even running natively on hundreds or millions of mobile devices which may not always have reliable connectivity to the internet. Similarly, our applications often need to source data and functionality from many systems both public and private. This has presented us with a major challenge: we simply don’t have the control we need to guarantee availability of our data, business logic, and third party functionality. Similarly, we often can’t guarantee that the data or functionality of our third party sources is in a format that is easily consumable by our systems.
To address this challenge, several new service based patterns have emerged. Namely, standardized interfaces accessed via common protocols, asynchronous messaging, standardized, platform-agnostic data structures, and standardized pass-through authentication. Concurrently, we have seen the rise of standardized presentation technologies that are platform agnostic, flexible and extensible.
Core Components of the Service Based Internet
As noted above, several patterns have emerged that enable the service based internet. Let’s take a look at the technologies currently supporting these patterns.
Although these technologies are components of the class of consuming systems that we call apps, it is important to examine them to understand how the ecosystem functions holistically. As our systems have becoming increasingly decoupled, and the available platforms through which we can access services has dramatically expanded, there has been an increasing need to find technologies that lend themselves to presenting data and functionality consistently regardless of the platform. This process has been an organic one with many promising technologies that have died along the way.
With the advent of smart mobile devices, we as developers have been faced with the task of developing for many and varied form factors and platforms. Early in the mobile revolution, we were often faced with the choice of developing native apps which had a rich integrated experience at the cost of needing to develop completely separate codebases for several different platforms or to develop web applications specifically designed for
mobile form factors at the cost of a less integrated experience and the need to host the presentation layer on a server.
These technologies are essentially stateless, and it should be understood that the reason these technologies work well for modern apps is because the heavy lifting is performed by services which support asynchronous communication with standardized protocols and interchange formats.
One of the core challenges of the Service Based Internet is the need for standardized protocols for interacting with services. Many technologies have been introduced to solve this problem, but most have either lacked true support for asynchronous communication or have supported it through complex subsystems like enterprise service busses or message queuing. Likewise, many of these technologies have directly leveraged the TCP or UDP stack, requiring complex client and server frameworks to support bidirectional communication.
REST, or Representational State Transfer, has arisen as a favored technology for several reasons: namely it is a fundamentally stateless technology, it almost always uses HTTP(s) as a transfer protocol, it is cacheable, it supports code-on-demand, and finally, it defines a uniform interface.
These features have several compelling advantages: The statelessness of the technology reduces the complexity of the underlying server code and simplifies scaling of the service across multiple servers. Similarly, the cacheability of the system reduces client-server interaction and allows for implicit or explicit instruction to the client regarding whether the data is cacheable and for how long it is valid. Additionally, HTTP is a well-established technology supported natively by every internet enabled platform, this allows us to leverage existing client and server frameworks instead of needing to implement plugins and extensions to our services to support other transfer protocols.
Lastly, the uniform interface defines a predictable mode of interaction with the service through four primary constraints: Identification of resources, manipulation of resources through their representations, self-descriptive messages, and Hypermedia (e.g. hyperlinks) as the engine of application state.
Leveraging client side asynchronous messaging patterns such as AJAJ allows us to gracefully handle the availability and reliability challenges inherent in the unregulated internet without the overhead of reliable messaging schemes. Our consuming systems should be designed to follow this pattern wherever possible
OAUTH is a standardized RESTful approach to providing delegated authorization to an app by specifying a process for allowing apps to authenticate to a resource (service) by logging in to the service directly and then managing the communication between the app and the service via access tokens. This eliminates the need for apps to store user credentials, thus limiting a potential security vulnerability. In addition to direct authentication to a service, OAuth is often used as a way for users to authenticate to a resource using a common account such as their Google, Twitter, Facebook, or Microsoft account, which reduces the complexity of the service as it no longer has to be concerned with managing user accounts.
The standard for OAuth is evolving and presents some challenges for mobile devices. However, the pattern of delegated authorization and negotiation via access tokens seems likely to stay. It behooves us to create our services to support his model of authorization wherever practical.
About Chris Sorel
Chris is a senior architect with Statera, focusing on enterprise application architecture and application development. Chris has spent many years in the industry evangelizing user-centric design and the role of custom software in helping companies stay innovative. When he’s not helping our clients, he can be found hiking one of Colorado’s 14ers or rock climbing in one of the front range canyons.