Welcome!

Microservices Expo Authors: Jason Bloomberg, Aruna Ravichandran, Robert Reeves, Pat Romanski, Flint Brenton

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
The notion of customer journeys, of course, are central to the digital marketer’s playbook. Clearly, enterprises should focus their digital efforts on such journeys, as they represent customer interactions over time. But making customer journeys the centerpiece of the enterprise architecture, however, leaves more questions than answers. The challenge arises when EAs consider the context of the customer journey in the overall architecture as well as the architectural elements that make up each...
Much of the discussion around cloud DevOps focuses on the speed with which companies need to get new code into production. This focus is important – because in an increasingly digital marketplace, new code enables new value propositions. New code is also often essential for maintaining competitive parity with market innovators. But new code doesn’t just have to deliver the functionality the business requires. It also has to behave well because the behavior of code in the cloud affects performan...
In 2006, Martin Fowler posted his now famous essay on Continuous Integration. Looking back, what seemed revolutionary, radical or just plain crazy is now common, pedestrian and "just what you do." I love it. Back then, building and releasing software was a real pain. Integration was something you did at the end, after code complete, and we didn't know how long it would take. Some people may recall how we, as an industry, spent a massive amount of time integrating code from one team with another...
SYS-CON Events announced today that Peak 10, Inc., a national IT infrastructure and cloud services provider, will exhibit at SYS-CON's 18th International Cloud Expo®, which will take place on June 7-9, 2016, at the Javits Center in New York City, NY. Peak 10 provides reliable, tailored data center and network services, cloud and managed services. Its solutions are designed to scale and adapt to customers’ changing business needs, enabling them to lower costs, improve performance and focus inter...
As the software delivery industry continues to evolve and mature, the challenge of managing the growing list of the tools and processes becomes more daunting every day. Today, Application Lifecycle Management (ALM) platforms are proving most valuable by providing the governance, management and coordination for every stage of development, deployment and release. Recently, I spoke with Madison Moore at SD Times about the changing market and where ALM is headed.
If there is anything we have learned by now, is that every business paves their own unique path for releasing software- every pipeline, implementation and practices are a bit different, and DevOps comes in all shapes and sizes. Software delivery practices are often comprised of set of several complementing (or even competing) methodologies – such as leveraging Agile, DevOps and even a mix of ITIL, to create the combination that’s most suitable for your organization and that maximize your busines...
Struggling to keep up with increasing application demand? Learn how Platform as a Service (PaaS) can streamline application development processes and make resource management easy.
The goal of any tech business worth its salt is to provide the best product or service to its clients in the most efficient and cost-effective way possible. This is just as true in the development of software products as it is in other product design services. Microservices, an app architecture style that leans mostly on independent, self-contained programs, are quickly becoming the new norm, so to speak. With this change comes a declining reliance on older SOAs like COBRA, a push toward more s...
This is not a small hotel event. It is also not a big vendor party where politicians and entertainers are more important than real content. This is Cloud Expo, the world's longest-running conference and exhibition focused on Cloud Computing and all that it entails. If you want serious presentations and valuable insight about Cloud Computing for three straight days, then register now for Cloud Expo.
SYS-CON Events announced today that Stratoscale, the software company developing the next generation data center operating system, will exhibit at SYS-CON's 18th International Cloud Expo®, which will take place on June 7-9, 2016, at the Javits Center in New York City, NY. Stratoscale is revolutionizing the data center with a zero-to-cloud-in-minutes solution. With Stratoscale’s hardware-agnostic, Software Defined Data Center (SDDC) solution to store everything, run anything and scale everywhere...
Digital means customer preferences and behavior are driving enterprise technology decisions to be sure, but let’s not forget our employees. After all, when we say customer, we mean customer writ large, including partners, supply chain participants, and yes, those salaried denizens whose daily labor forms the cornerstone of the enterprise. While your customers bask in the warm rays of your digital efforts, are your employees toiling away in the dark recesses of your enterprise, pecking data into...
SYS-CON Events announced today that Men & Mice, the leading global provider of DNS, DHCP and IP address management overlay solutions, will exhibit at SYS-CON's 18th International Cloud Expo®, which will take place on June 7-9, 2016, at the Javits Center in New York City, NY. The Men & Mice Suite overlay solution is already known for its powerful application in heterogeneous operating environments, enabling enterprises to scale without fuss. Building on a solid range of diverse platform support,...
You deployed your app with the Bluemix PaaS and it's gaining some serious traction, so it's time to make some tweaks. Did you design your application in a way that it can scale in the cloud? Were you even thinking about the cloud when you built the app? If not, chances are your app is going to break. Check out this webcast to learn various techniques for designing applications that will scale successfully in Bluemix, for the confidence you need to take your apps to the next level and beyond.
I had the opportunity to catch up with Chris Corriere - DevOps Engineer at AutoTrader - to talk about his experiences in the realm of Rugged DevOps. We discussed automation, culture and collaboration, and which thought leaders he is following. Chris Corriere: Hey, I'm Chris Corriere. I'm a DevOps Engineer AutoTrader. Derek Weeks: Today we're going to talk about Rugged DevOps. It's a subject that's gaining a lot of traction in the community but not a lot of people are really familiar with wh...
Wow, if you ever wanted to learn about Rugged DevOps (some call it DevSecOps), sit down for a spell with Shannon Lietz, Ian Allison and Scott Kennedy from Intuit. We discussed a number of important topics including internal war games, culture hacking, gamification of Rugged DevOps and starting as a small team. There are 100 gold nuggets in this conversation for novices and experts alike.
SYS-CON Events announced today that DatacenterDynamics has been named “Media Sponsor” of SYS-CON's 18th International Cloud Expo, which will take place on June 7–9, 2016, at the Javits Center in New York City, NY. DatacenterDynamics is a brand of DCD Group, a global B2B media and publishing company that develops products to help senior professionals in the world's most ICT dependent organizations make risk-based infrastructure and capacity decisions.
With DevOps becoming more well-known and established practice in nearly every industry that delivers software, it is important to continually reassess its efficacy. This week’s top 10 includes a discussion on how the quick uptake of DevOps adoption in the enterprise has posed some serious challenges. Additionally, organizations who have taken the DevOps plunge must find ways to find, hire and keep their DevOps talent in order to keep the machine running smoothly.
Call it DevOps or not, if you are concerned about releasing more code faster and at a higher quality, the resulting software delivery chain and process will look and smell like DevOps. But for existing development teams, no matter what the velocity objective is, getting from here to there is not something that can be done without a plan. Moving your release cadence from months to weeks is not just about learning Agile practices and getting some automation tools. It involves people, tooling and ...
Between the mockups and specs produced by analysts, and resulting applications built by developers, there exists a gulf where projects fail, costs spiral, and applications disappoint. Methodologies like Agile attempt to address this with intensified communication, with partial success but many limitations. In his session at 18th Cloud Expo, Charles Kendrick, CTO & Chief Architect at Isomorphic Software, will present a revolutionary model enabled by new technologies. Learn how business and devel...
APIs have taken the world by storm in recent years. The use of APIs has gone beyond just traditional "software" companies, to companies and organizations across industries using APIs to share information and power their applications. For some organizations, APIs are the biggest revenue drivers. For example, Salesforce generates nearly 50% of annual revenue through APIs. In other cases, APIs can increase a business's footprint and initiate collaboration. Netflix, for example, reported over 5 bi...