man with word clouds

Core Components of the Service Based Internet

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.

HTML 5, CSS 3 and JavaScript

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.

The internet has spoken, however, and remarkably, HTML, CSS, and JavaScript – the core technologies of the old web – have been found to be the best technologies for supporting consistent presentation across various platforms, form factors, and devices.

With the revolutionary changes introduced in HTML 5 and CSS 3, these technologies have proven to be remarkably capable at structuring and presenting data and functionality. Likewise, JavaScript has proven to be remarkably capable at communicating with services to operate on and retrieve data and providing event driven functionality to support responsive and fluid user experiences.

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.

A new option has emerged, however, and is providing a bridge between the two models. Several frameworks now exist that run natively on all device platforms and leverage HTML 5, CSS 3, and JavaScript as their primary presentation technologies.

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.

Code on demand allows the service to extend the client or server’s functionality through the delivery of packaged code such as JavaScript which explicitly defines the actions to perform upon successful or unsuccessful completion of the request.

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.



Object Notation, or JSON, is a human-readable standardized format for representing an object graph in a platform agnostic format. The goal of JSON is to provide a format that is easily generated and consumable by all services and consumers of services. JSON arose as an alternative to XML largely because it is natively parsed by JavaScript as objects, thus not requiring extensive coding to parse, as is necessary for XML in JavaScript. The format has caught on in other languages and is now natively supported on most browsers. As such JSON has now supplanted XML as the primary format for transmitting ad-hoc structured data between services and consumers and should be the preferred choice for all data returned or accepted by services.

Asynchronous JavaScript

Asynchronous JavaScript, often called AJAX or AJAJ (Asynchronous JavaScript and JSON), is a series of techniques and frameworks which allow for the retrieval of data asynchronously without interfering with the loading, execution, or display of an interface. AJAJ is a key component of the service based internet because it allows consumer systems to make calls to services and await response without blocking the primary thread. Additionally, it provides the ability to point to success and failure routines to be executed upon response from the service as well as in response to a timeout or other critical failure in the service call.

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.