Welcome!

Microservices Expo Authors: Elizabeth White, Liz McMillan, Andy Thurai, Pat Romanski, John Katrick

Related Topics: Microservices Expo

Microservices Expo: Article

Considering a RESTful Approach to Net-Centricity

REST and the DoD's Net-Centric Data Strategy

In May of 2003, the CIO of the Department of Defense established the Net-Centric Data Strategy [NCDS] as part of its transformation to Net-Centricity.   The DoD's goal of Net-Centricity is the creation of a network of people, processes, systems, and infrastructure that enables a new approach to warfighting and business operations with improved military situational awareness, better access to business information, and dramatically shortened decision cycles.  The Net-Centric Data Strategy addresses the key element that is required to make all this happen—information-sharing. Its main tenets are to make all data within the DoD visible, accessible, and understandable so that warfighters and civilian personnel have timely access to the information that they need to effectively accomplish their mission.

Since then, many programs within the DoD have embarked on the journey of making their systems more “net-centric" by applying principles of service-oriented architectures and using web service technologies to expose and share the data within those systems. As with many large enterprises, the DoD has adopted the SOAP WS-* approach to create web services.  WS-* refers to the myriad of web service standards and specifications such as WS-Security, WS-Notification, WS-Policy, etc. The DoD is a large and complex organization with unique requirements, especially in the area of security, that require the use of many of these WS-* standards and specifications.

Although the DoD has had some initial successes using SOAP and WS-*, the popularity and success that is seen on the Web with the REST approach to web services should not be ignored. For example, the REST-based services of Amazon.com, one of the best-known examples of successful web services implementations in the commercial world, are much more widely used than its SOAP-based services.  The popularity and success of REST has been so widespread that even Microsoft, one of the originators and primary supporters of WSDL, SOAP, and many of the WS-* specifications, has not been able to ignore it.  In its latest version of .NET, Microsoft has added the ADO.NET Data Services that provide a framework for the creation and consumption of RESTful data services for the web. Given this growing popularity and support for REST, the DoD would be remiss if it did not consider REST in its implementation of the Net-Centric Data Strategy.

The purpose of this article is not to argue whether or not REST is a better approach than SOAP and WS-*, but to examine the principles of REST and how they align with the objectives and tenets of the DoD's Net-Centric Data Strategy.   This examination will reveal areas where the DoD may be able to use REST in conjunction with its current approach to achieve a more effective implementation of the Net-Centric Data Strategy.

Principles of REST
REST is an acronym for Representational State Transfer, a term introduced by Roy Fielding in his dissertation [FIELDING] to describe the architectural style of the Web.  Fielding was one of the key authors of HTTP and other Web standards and applied REST in the design of those standards.  The REST style is based on a client-server architecture that emphasizes a high level of abstraction, scalability, and maximum interoperability. In recent years, the REST style has been increasingly used in the design and implementation of web services. In the REST style, services are modeled as a set of resources and clients interact with the services by transferring representations that capture the state of those resources.  The objectives of the REST style are achieved through four key constraints that are applied against the architecture:

Uniform Interface - this is one of the most distinguishing and important features of REST. This constraint requires all resources to expose the same interface. The benefit of this is the simplicity and interoperability that is achieved through a single interface for all interactions.

Self-Descriptive Messages—this means that recipients should be able to understand a message using only the information contained in that message. To achieve this, messages should be based on standard media types and contain all the necessary metadata to describe them.

Addressable Resources—every resource should be assigned an identifier based on a universal syntax that makes the resource uniquely addressable. For example, on the Web, every resource is assigned a URI so that it can be referenced and accessed.

Hypermedia as the Engine of Application State—the representations of resources should contains paths (or links) to other related resources.Others have referred to this simply as the principle of “connectedness”—resources are connected to other relevant resources through links in their representations [RICHARDSON RUBY].

REST and Net-Centricity
A close examination of the Net-Centric Data Strategy reveals that REST principles are aligned to the net-centricity objectives of the DoD. The main tenets that are espoused by the Net-Centric Data Strategy are to make data visible, accessible, and understandable to both anticipated and unanticipated users. At first glance, these may seem simple and perhaps even trivial. However, the complexity lies in the scale in which the DoD is trying to achieve this. This is in many ways analogous to what the Web was trying to achieve. Tim Berners-Lee once wrote that “the goal of the Web was to be a shared information space through which people and machines could communicate” [WWW PPF]. The notion of a shared space is also central to the Net-Centric Data Strategy, which describes it as an area where users and applications post all data assets so that they can be shared by the DoD enterprise. Given the similarities, it is natural that REST being the architectural style of the Web will offer some key principles and guidelines that are applicable to the DoD’s implementation of the Net-Centric Data Strategy. To understand the synergies between REST and the Net-Centric Data Strategy, it is helpful to see how REST principles support each of the core tenets.

“Make Data Visible, …”
Making data visible means that users and applications (consumers of the data) can discover the existence of that data. Applying the REST principle of addressable resources means that every piece of data that is be exposed and shared would have an URI that allows that data to be indexed by search engines, registered in some catalog or registry or simply passed around through email—all of which enable that data to be discovered. The other principle supporting the visibility tenet is hypermedia as the engine of application state. As described earlier, this principle states that the representations of resources should contain links (URIs) to other relevant resources. Thus, from one piece of data, the user can discover other relevant data through the links that are present. The significance of this to information-sharing is important and will be discussed more later.

“Accessible…”
Once the data is discovered, in order to use that data, the consumer must be able to access it. The REST principle that supports the accessibility tenet is also the principle of addressable resources. Going back to the notion of a shared space for data, when a resource or a piece of data is assigned an URI, it has an address in that space. When something has an address, others will know how to get to it, or in other words it can be accessed. With the address available, the consumer can now use the protocol of the shared space to retrieve the data. If the shared space supports the principle of uniform interfaces, then all resources expose the same interface for access so any consumer will know how to access any resource. Thus, the uniform interface enables ubiquitous access to data.

“And Understandable…”
Finally, once the consumer has discovered and accessed the data, it needs to be able to understand it in order to use it. The REST principle of self-descriptive messages helps to make data understandable. According to this principle, all messages (or in this case data) should be based on standard representation formats and contain the necessary metadata to describe the content. Constraining data to be based on standard formats ensures that it is understandable by a broad audience. Requiring every message to contain metadata ensures that consumers know which standard formats are being used to represent the data.  In addition to the syntactic agreement enabled by self-descriptive messages, REST also enhances understandability by allowing data to be presented with links to other related data. This is enabled by the principles of addressable resources and hypermedia as the engine of application state—this was alluded to earlier in the discussion on the data visibility tenet. Applying the first principle, every piece of data that is exposed and shared would have an URI assigned to it. Next, following the principle of hypermedia as the engine of application state, these URIs can then be used to allow those individual pieces of data that are related to reference or link to each other. These links create a context around every piece of data that is shared, which enables a more accurate understanding of that data.

“Supporting the Unanticipated User…”
To implement the data strategy, communities of interest (COIs) across the DoD coalesce around logical families of data and design services to enable the sharing of that data. However, the strategy calls for data to be made visible, accessible, and understandable to both anticipated and unanticipated users. So that begs the question—how does one design a service for users that have not yet been anticipated? And conversely, how will a user that was not anticipated understand how to use a service it has just discovered? With regards to supporting the unanticipated user, no other system has done this better than the Web. In fact, that is the main objective of the Web—to make data available so that any user who is interested can access and use it. Primarily, it is the principle of uniform interfaces that has allowed the Web to so successfully support the model of unanticipated usage. Applying this principle means that all users, anticipated or not, interact with a service through the same interface. Thus, nothing special is required to design the service so that it can support the unanticipated user (at least from the interface design perspective). In addition to a service exposing the same interface for all users, all services also expose the same interface. Because all services expose the same interface, a user will know how to utilize a new service that it has just discovered based on past usage of other services. In other words, a user only needs to learn how to interact with one interface since all services expose that same interface.  Some may argue that it is not practical or perhaps even possible for all services to expose the same interface. This is in fact one of the most highly debated issues between those in the REST camp and those in the SOAP WS-* camp. However, most people from both camps will agree that the uniform interface works well for scenarios in which data needs to be exposed through a web service that primarily provides read access. These scenarios represent a majority of the current efforts in the DoD’s implementation of the Net-Centric Data Strategy.

The Need for Both Approaches
Because of the size and complexity of its environment, there is no one-size-fits-all approach that can readily support all the requirements and constraints of the DoD. There are scenarios in which the SOAP WS-* approach is more applicable and others in which the RESTful approach is more applicable.

The SOAP WS-* approach provides a broad set of standards and specifications for quality of service features and also gives developers a lot of flexibility to define custom interfaces for the services that they wish to expose. This flexibility is useful for application-to-application integration scenarios internal to an organization. This is also useful in scenarios in which legacy applications need to be exposed to the rest of the enterprise. In either of these scenarios, the existing applications often constrain how the services may be exposed, so the flexibility to design service interfaces that can adapt to these constraints is important. Additionally, in these scenarios the services are often providing complex functionality and processes that may be difficult to model in a resource-oriented manner with uniform interfaces. It is also these types of scenarios that typically require many of the complex quality of service features that the SOAP WS-* approach has broad support for. Finally, these types of scenarios are more commonly found inside a single organization and less so across organizational boundaries. The SOAP WS-* approach typically results in large number of custom interfaces, but when this is occurring within a single organization, they are a lot easier to control and maintain than in scenarios where there are many organizations that are dependent on those interfaces.

The RESTful approach on the other hand, is very attractive for those large scale integration scenarios that cross many organizational boundaries. This is because the constraints imposed by the REST principles emphasize interoperability and scalability. The constraint of uniform interfaces supports those scenarios in which the consumer base for the services is so broad that it makes it difficult to create and maintain a large set of custom interfaces. In such cases, it makes more sense to apply a design in which a single interface can support all the required interactions. Unfortunately, modeling everything as a set of resources that are all exposed through a uniform interface is not always easy. Developers are accustomed to designing a specific interface for each piece of functionality or data that they wish to expose; forcing them to always use a uniform interface is antithetical to this. However, scenarios in which services are just providing access to data can easily support the uniform interface constraint.This is because any kind of data can be manipulated through the same set of create, read, update, and delete operations. Thus, scenarios in which it is primarily data that needs to be shared through web services make REST an easy choice.

This article has shown the synergies that exist between REST and the core tenets of the DoD’s Net-Centric Data Strategy, as well as the benefits to be gained from applying REST principles in the implementation of that strategy. Table 1 summarizes those synergies and benefits.

REST Principle

Alignment with Net-Centric Data Strategy

Uniform Interfaces

  • All resources exposing the same uniform interface enables ubiquitous access to data
  • Supports the unanticipated user since all users anticipated or not access resources through the same uniform interface

Self-Descriptive Messages

  • Use of standard representation formats and descriptive metadata enables data to be understandable by a broad audience

Addressable Resources

  • Every resource or piece of data has an addressable URI making it discoverable and thus increases its visibility
  • The URI not only allows the resource to be discovered, but also allows it to be accessed
  • These URIs also allow information to be linked to provide context to increase understandability

Hypermedia as the Engine of Application State

  • This principle of “connectedness” requires resources to contain links to other relevant resources, enabling related resources to be discoverable through each other’s representations
  • This connectedness of resources results in a network of information that provides the context to increase understandability

Table 1: Summary of synergies between REST and Net-Centric Data Strategy

As stated in the introduction, the purpose of this article was not to argue whether or not REST is a better approach than SOAP and WS-* in the implementation of the Net-Centric Data Strategy. Instead, the intent here was to highlight the synergies and benefits of REST so that those responsible for implementation may open their eyes to an alternative approach that may be more effective in certain scenarios. It is hoped that after reading this article, they will consider a RESTful approach to Net-Centricity when they encounter those scenarios.

References
[FIELDING] Fielding, Roy Thomas. “Architectural Styles and the Design of Network-based Software Architectures”. Doctoral dissertation, University of California, Irvine, 2000. http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

[NCDS] Department of Defense, Chief Information Officer. “Department of Defense Net-Centric Data Strategy.” May 9, 2003. http://www.defenselink.mil/cio-nii/docs/Net-Centric-Data-Strategy-2003-05-092.pdf

[RICHARDSON RUBY] Richardson, Leonard; Ruby, Sam. “RESTful Web Services.” May 2007.

[WWW PPF] Berners-Lee, Tim. “The World Wide Web: Past, Present, Future.” August 1996. http://www.w3.org/People/Berners-Lee/1996/ppf.html

More Stories By Tieu Luu

Tieu Luu works at SuprTEK where he helps the U.S. government create and implement strategies and architectures that apply innovative technologies and approaches in IT. You can read more of Tieu’s writing at his blog at http://tieuluu.com/blog.

@MicroservicesExpo Stories
In his session at @DevOpsSummit at 20th Cloud Expo, Kelly Looney, director of DevOps consulting for Skytap, showed how an incremental approach to introducing containers into complex, distributed applications results in modernization with less risk and more reward. He also shared the story of how Skytap used Docker to get out of the business of managing infrastructure, and into the business of delivering innovation and business value. Attendees learned how up-front planning allows for a clean sep...
"I focus on what we are calling CAST Highlight, which is our SaaS application portfolio analysis tool. It is an extremely lightweight tool that can integrate with pretty much any build process right now," explained Andrew Siegmund, Application Migration Specialist for CAST, in this SYS-CON.tv interview at 21st Cloud Expo, held Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA.
In IT, we sometimes coin terms for things before we know exactly what they are and how they’ll be used. The resulting terms may capture a common set of aspirations and goals – as “cloud” did broadly for on-demand, self-service, and flexible computing. But such a term can also lump together diverse and even competing practices, technologies, and priorities to the point where important distinctions are glossed over and lost.
"I will be talking about ChatOps and ChatOps as a way to solve some problems in the DevOps space," explained Himanshu Chhetri, CTO of Addteq, in this SYS-CON.tv interview at @DevOpsSummit at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.
Kin Lane recently wrote a couple of blogs about why copyrighting an API is not common. I couldn’t agree more that copyrighting APIs is uncommon. First of all, the API definition is just an interface (It is the implementation detail … Continue reading →
The United States spends around 17-18% of its GDP on healthcare every year. Translated into dollars, it is a mind-boggling $2.9 trillion. Unfortunately, that spending will grow at a faster rate now due to baby boomers becoming an aging population, and they are the largest demographic in the U.S. Unless the U.S. gets this spiraling healthcare spending under control, in a few short years we will be spending almost 25% of our entire GDP in healthcare trying to fix people’s failing health, instead o...
You know you need the cloud, but you’re hesitant to simply dump everything at Amazon since you know that not all workloads are suitable for cloud. You know that you want the kind of ease of use and scalability that you get with public cloud, but your applications are architected in a way that makes the public cloud a non-starter. You’re looking at private cloud solutions based on hyperconverged infrastructure, but you’re concerned with the limits inherent in those technologies.
For organizations that have amassed large sums of software complexity, taking a microservices approach is the first step toward DevOps and continuous improvement / development. Integrating system-level analysis with microservices makes it easier to change and add functionality to applications at any time without the increase of risk. Before you start big transformation projects or a cloud migration, make sure these changes won’t take down your entire organization.
When you focus on a journey from up-close, you look at your own technical and cultural history and how you changed it for the benefit of the customer. This was our starting point: too many integration issues, 13 SWP days and very long cycles. It was evident that in this fast-paced industry we could no longer afford this reality. We needed something that would take us beyond reducing the development lifecycles, CI and Agile methodologies. We made a fundamental difference, even changed our culture...
In his session at 20th Cloud Expo, Mike Johnston, an infrastructure engineer at Supergiant.io, discussed how to use Kubernetes to set up a SaaS infrastructure for your business. Mike Johnston is an infrastructure engineer at Supergiant.io with over 12 years of experience designing, deploying, and maintaining server and workstation infrastructure at all scales. He has experience with brick and mortar data centers as well as cloud providers like Digital Ocean, Amazon Web Services, and Rackspace. H...
You often hear the two titles of "DevOps" and "Immutable Infrastructure" used independently. In his session at DevOps Summit, John Willis, Technical Evangelist for Docker, covered the union between the two topics and why this is important. He provided an overview of Immutable Infrastructure then showed how an Immutable Continuous Delivery pipeline can be applied as a best practice for "DevOps." He ended the session with some interesting case study examples.
"DivvyCloud as a company set out to help customers automate solutions to the most common cloud problems," noted Jeremy Snyder, VP of Business Development at DivvyCloud, in this SYS-CON.tv interview at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.
Without lifecycle traceability and visibility across the tool chain, stakeholders from Planning-to-Ops have limited insight and answers to who, what, when, why and how across the DevOps lifecycle. This impacts the ability to deliver high quality software at the needed velocity to drive positive business outcomes. In his general session at @DevOpsSummit at 19th Cloud Expo, Eric Robertson, General Manager at CollabNet, will discuss how customers are able to achieve a level of transparency that e...
The Jevons Paradox suggests that when technological advances increase efficiency of a resource, it results in an overall increase in consumption. Writing on the increased use of coal as a result of technological improvements, 19th-century economist William Stanley Jevons found that these improvements led to the development of new ways to utilize coal. In his session at 19th Cloud Expo, Mark Thiele, Chief Strategy Officer for Apcera, compared the Jevons Paradox to modern-day enterprise IT, examin...
We all know that end users experience the internet primarily with mobile devices. From an app development perspective, we know that successfully responding to the needs of mobile customers depends on rapid DevOps – failing fast, in short, until the right solution evolves in your customers' relationship to your business. Whether you’re decomposing an SOA monolith, or developing a new application cloud natively, it’s not a question of using microservices - not doing so will be a path to eventual ...
In his session at 20th Cloud Expo, Scott Davis, CTO of Embotics, discussed how automation can provide the dynamic management required to cost-effectively deliver microservices and container solutions at scale. He also discussed how flexible automation is the key to effectively bridging and seamlessly coordinating both IT and developer needs for component orchestration across disparate clouds – an increasingly important requirement at today’s multi-cloud enterprise.
Containers are rapidly finding their way into enterprise data centers, but change is difficult. How do enterprises transform their architecture with technologies like containers without losing the reliable components of their current solutions? In his session at @DevOpsSummit at 21st Cloud Expo, Tony Campbell, Director, Educational Services at CoreOS, will explore the challenges organizations are facing today as they move to containers and go over how Kubernetes applications can deploy with lega...
Your homes and cars can be automated and self-serviced. Why can't your storage? From simply asking questions to analyze and troubleshoot your infrastructure, to provisioning storage with snapshots, recovery and replication, your wildest sci-fi dream has come true. In his session at @DevOpsSummit at 20th Cloud Expo, Dan Florea, Director of Product Management at Tintri, provided a ChatOps demo where you can talk to your storage and manage it from anywhere, through Slack and similar services with...
Learn how to solve the problem of keeping files in sync between multiple Docker containers. In his session at 16th Cloud Expo, Aaron Brongersma, Senior Infrastructure Engineer at Modulus, discussed using rsync, GlusterFS, EBS and Bit Torrent Sync. He broke down the tools that are needed to help create a seamless user experience. In the end, can we have an environment where we can easily move Docker containers, servers, and volumes without impacting our applications? He shared his results so yo...
Enterprise architects are increasingly adopting multi-cloud strategies as they seek to utilize existing data center assets, leverage the advantages of cloud computing and avoid cloud vendor lock-in. This requires a globally aware traffic management strategy that can monitor infrastructure health across data centers and end-user experience globally, while responding to control changes and system specification at the speed of today’s DevOps teams. In his session at 20th Cloud Expo, Josh Gray, Chie...