Click here to close now.

Welcome!

@MicroservicesE Blog Authors: Pat Romanski, Lori MacVittie, Elizabeth White, Liz McMillan, XebiaLabs Blog

Related Topics: @MicroservicesE Blog

@MicroservicesE Blog: 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
DevOps tends to focus on the relationship between Dev and Ops, putting an emphasis on the ops and application infrastructure. But that’s changing with microservices architectures. In her session at DevOps Summit, Lori MacVittie, Evangelist for F5 Networks, will focus on how microservices are changing the underlying architectures needed to scale, secure and deliver applications based on highly distributed (micro) services and why that means an expansion into “the network” for DevOps.
Conferences agendas. Event navigation. Specific tasks, like buying a house or getting a car loan. If you've installed an app for any of these things you've installed what's known as a "disposable mobile app" or DMA. Apps designed for a single use-case and with the expectation they'll be "thrown away" like brochures. Deleted until needed again. These apps are necessarily small, agile and highly volatile. Sometimes existing only for a short time - say to support an event like an election, the Wor...
Containers have changed the mind of IT in DevOps. They enable developers to work with dev, test, stage and production environments identically. Containers provide the right abstraction for microservices and many cloud platforms have integrated them into deployment pipelines. DevOps and Containers together help companies to achieve their business goals faster and more effectively. In his session at DevOps Summit, Ruslan Synytsky, CEO and Co-founder of Jelastic, reviewed the current landscape of...
The cloud has transformed how we think about software quality. Instead of preventing failures, we must focus on automatic recovery from failure. In other words, resilience trumps traditional quality measures. Continuous delivery models further squeeze traditional notions of quality. Remember the venerable project management Iron Triangle? Among time, scope, and cost, you can only fix two or quality will suffer. Only in today's DevOps world, continuous testing, integration, and deployment upend...
Discussions about cloud computing are evolving into discussions about enterprise IT in general. As enterprises increasingly migrate toward their own unique clouds, new issues such as the use of containers and microservices emerge to keep things interesting. In this Power Panel at 16th Cloud Expo, moderated by Conference Chair Roger Strukhoff, panelists addressed the state of cloud computing today, and what enterprise IT professionals need to know about how the latest topics and trends affect t...
Explosive growth in connected devices. Enormous amounts of data for collection and analysis. Critical use of data for split-second decision making and actionable information. All three are factors in making the Internet of Things a reality. Yet, any one factor would have an IT organization pondering its infrastructure strategy. How should your organization enhance its IT framework to enable an Internet of Things implementation? In his session at @ThingsExpo, James Kirkland, Red Hat's Chief Arch...
Summer is finally here and it’s time for a DevOps summer vacation. From San Francisco to New York City, our top summer conferences list is going to continuously deliver you to the summer destinations of your dreams. These DevOps parties are hitting all the hottest summer trends with Microservices, Agile, Continuous Delivery, DevSecOps, and even Continuous Testing. Move over Kanye. These are the top 5 Summer DevOps Conferences of 2015.
Sharding has become a popular means of achieving scalability in application architectures in which read/write data separation is not only possible, but desirable to achieve new heights of concurrency. The premise is that by splitting up read and write duties, it is possible to get better overall performance at the cost of a slight delay in consistency. That is, it takes a bit of time to replicate changes initiated by a "write" to the read-only master database. It's eventually consistent, and it'...
"Plutora provides release and testing environment capabilities to the enterprise," explained Dalibor Siroky, Director and Co-founder of Plutora, in this SYS-CON.tv interview at @DevOpsSummit, held June 9-11, 2015, at the Javits Center in New York City.
Containers are changing the security landscape for software development and deployment. As with any security solutions, security approaches that work for developers, operations personnel and security professionals is a requirement. In his session at DevOps Summit, Kevin Gilpin, CTO and Co-Founder of Conjur, will discuss various security considerations for container-based infrastructure and related DevOps workflows.
Cloud Migration Management (CMM) refers to the best practices for planning and managing migration of IT systems from a legacy platform to a Cloud Provider through a combination professional services consulting and software tools. A Cloud migration project can be a relatively simple exercise, where applications are migrated ‘as is’, to gain benefits such as elastic capacity and utility pricing, but without making any changes to the application architecture, software development methods or busine...
Data center models are changing. A variety of technical trends and business demands are forcing that change, most of them centered on the explosive growth of applications. That means, in turn, that the requirements for application delivery are changing. Certainly application delivery needs to be agile, not waterfall. It needs to deliver services in hours, not weeks or months. It needs to be more cost efficient. And more than anything else, it needs to be really, dc infra axisreally, super focus...
The most often asked question post-DevOps introduction is: “How do I get started?” There’s plenty of information on why DevOps is valid and important, but many managers still struggle with simple basics for how to initiate a DevOps program in their business. They struggle with issues related to current organizational inertia, the lack of experience on Continuous Integration/Delivery, understanding where DevOps will affect revenue and budget, etc. In their session at DevOps Summit, JP Morgenthal...
Overgrown applications have given way to modular applications, driven by the need to break larger problems into smaller problems. Similarly large monolithic development processes have been forced to be broken into smaller agile development cycles. Looking at trends in software development, microservices architectures meet the same demands. Additional benefits of microservices architectures are compartmentalization and a limited impact of service failure versus a complete software malfunction. ...
Many people recognize DevOps as an enormous benefit – faster application deployment, automated toolchains, support of more granular updates, better cooperation across groups. However, less appreciated is the journey enterprise IT groups need to make to achieve this outcome. The plain fact is that established IT processes reflect a very different set of goals: stability, infrequent change, hands-on administration, and alignment with ITIL. So how does an enterprise IT organization implement change...
While DevOps most critically and famously fosters collaboration, communication, and integration through cultural change, culture is more of an output than an input. In order to actively drive cultural evolution, organizations must make substantial organizational and process changes, and adopt new technologies, to encourage a DevOps culture. Moderated by Andi Mann, panelists discussed how to balance these three pillars of DevOps, where to focus attention (and resources), where organizations migh...
At DevOps Summit NY there’s been a whole lot of talk about not just DevOps, but containers, IoT, and microservices. Sessions focused not just on the cultural shift needed to grow at scale with a DevOps approach, but also made sure to include the network ”plumbing” needed to ensure success as applications decompose into the microservice architectures enabling rapid growth and support for the Internet of (Every)Things.
Mashape is bringing real-time analytics to microservices with the release of Mashape Analytics. First built internally to analyze the performance of more than 13,000 APIs served by the mashape.com marketplace, this new tool provides developers with robust visibility into their APIs and how they function within microservices. A purpose-built, open analytics platform designed specifically for APIs and microservices architectures, Mashape Analytics also lets developers and DevOps teams understand w...
Buzzword alert: Microservices and IoT at a DevOps conference? What could possibly go wrong? In this Power Panel at DevOps Summit, moderated by Jason Bloomberg, the leading expert on architecting agility for the enterprise and president of Intellyx, panelists peeled away the buzz and discuss the important architectural principles behind implementing IoT solutions for the enterprise. As remote IoT devices and sensors become increasingly intelligent, they become part of our distributed cloud envir...
Sumo Logic has announced comprehensive analytics capabilities for organizations embracing DevOps practices, microservices architectures and containers to build applications. As application architectures evolve toward microservices, containers continue to gain traction for providing the ideal environment to build, deploy and operate these applications across distributed systems. The volume and complexity of data generated by these environments make monitoring and troubleshooting an enormous chall...