Click here to close now.




















Welcome!

Microservices Expo Authors: Pat Romanski, Liz McMillan, VictorOps Blog, Elizabeth White, Trevor Parsons

Related Topics: Microservices Expo, Containers Expo Blog

Microservices Expo: Article

REST-Based SOA: an Iconoclastic Approach

Architecture that actually works is more important than following a dogmatic approach

At ZapThink we’re proud to be iconoclasts. After all, building agile architectures requires critical appraisal—and frequent dismissal—of traditionally held beliefs. We know this role places us among the heretics who dare challenge established dogma.

In fact, the whole notion of agility has long suffered this battle between iconoclasm and dogmatism. As we discuss in our Licensed ZapThink Architect course, the Agile Manifesto embodies an iconoclastic approach to software development dogma – and yet, so many people have become dogmatic about the Agile Manifesto itself, entirely missing its point!

ZapThink once more jumped into this iconoclasm-masquerading-as-dogma fray with our recent ZapFlash, How I Became a REST “Convert.” We explained how you can implement SOA following REST principles, and how such an approach introduces important simplifications and efficiencies as compared to a Web Services-based approach.

Get out the torches and pitchforks! ZapThink is at it again! Not only are we flying in the face of established SOA dogma, we’re taking on REST dogma as well! Never mind that the original vision for the REST movement was inherently iconoclastic. In fact, it’s no wonder that RESTafarians use religious metaphors in their discussions (although Rastafarianism is a far cry indeed from the Catholic metaphors we’re leveraging in this ZapFlash).

To quote our beloved Agile Manifesto, we want to favor responding to change over following a plan—even if that plan is how SOA or even REST is “supposed to be done.” The goal is stuff that actually addresses the business problem, not some adherence to official dogma (another Agile principle, in case you didn’t notice). Therefore, it came as no surprise to us when an organization contacted us and let us know that they are taking the REST-based SOA approach we discussed in the ZapFlash, and that it actually works.

The Iconoclastic REST-based SOA of the US Coast Guard
We recently spoke with the US Coast Guard (USCG) about their SPEAR (Semper Paratus: Enterprise Architecture Realization) initiative. The SPEAR approach to SOA centers on document-centric, event-driven, loosely coupled, asynchronous, message-based Business Services. Now, there’s nothing particularly iconoclastic about event-driven SOA—after all, we debunked that notion back in 2004—but their story doesn’t end there. Another central characteristic of their SOA approach is their document-centricity. While it’s true that document style interfaces are the norm for Web Services, the USCG takes the notion to a new level.

In the Web Services world, when a WSDL file specifies a document style interface, then the constraints on the input and output messages fall into one or more schema definitions, instead of the SOAP message structure itself. As far as SOAP is concerned, the body of the SOAP message contains a payload consisting of whatever document you like. The advantage of the document style over the tightly coupled remote procedure call (RPC) style is it allows for flexible versioning of Services: many changes to a Service do not force a new contract version.

However, as anyone who has monkeyed with Web Services can attest, the operations of a Service still cause issues, even when it’s a document style interface. We can’t seem to get away from Web Services’ tightly coupled RPC heritage. And furthermore, XML schemas are strongly typed, which introduces a further undesirable level of tight coupling.

To resolve such issues, REST moves the operations out of any formal contract, instead relying upon the GET, POST, PUT and DELETE operations best known from HTTP. Even so, there’s no requirement in REST that resources are necessarily documents. True, URLs that point to documents are a common and familiar pattern, but URLs could as easily point to abstracted method calls as well.

SPEAR takes document-centricity to the next level. For SPEAR, the document is the interface. It has meaning both for human and machine consumption. It’s self-describing and removes the need for defining a specific, formal contract. Instead, the USCG provides a basic header/body document structure. The header contains elements like requester, type, ID, timestamps, and status (request, response, publication or error, for example). The body contains different parts depending upon the type of Service. Request/response Services, for example, include elements like request, response, publication, and exception. As a result, SPEAR’s Service contracts (if you even decide to call them that) consist of a simple document structure and core REST operations—nothing more.

Maintaining State the Service-Oriented Way
For example, take a straightforward request/response Service that executes a simple database query. The Service simply populates the response field in the request document and returns the entire document to the requester. As a result, the document still contains the timestamped request. The ESB can now publish the document or put it on a queue, and the document itself acts as its own cache.

This approach to state is a simple example of a new trend in REST-based state management: Hypermedia as the Engine of Application State (HATEOAS). With HATEOAS, documents and the hyperlinks they contain represent all the state information a distributed environment requires. Want to know the next step in a process? Simply follow the appropriate link.

In the case of SPEAR, the USCG has established an internal standard URI representation: domain://provider:context/resource. For example, service://uscg.mda.vesselCrew:test/sla. The domain represents a taxonomy of resource types, including system://, organization://, geography://, and service://. The provider component represents the address to the provider of the resource. The context (squeezed in where ports go in a URL), represents the business context like :test, :dev, :stage, etc.

The ESB then resolves URIs to the physical endpoint references, acting as a routing engine that delivers the Business Service abstraction. Any hyperlink to such a URI, therefore, points to a document that contains all the state information the system requires, and furthermore, the architecture offers late binding to Services as a key feature. There is no build time mapping to any particular resource. Instead of using strongly typed schemas, they rely upon dynamic, loose typing in the documents. Such an approach is decidedly not Web Services-friendly.

It’s also important to note that state maintenance in the Web Services world has always been problematic. There are basically three ways to main state information in interactions among inherently stateless Services: rely upon the Service consumer to maintain a correlation ID (either not broadly adopted or relies upon an underlying protocol like HTTP cookies); rely upon the underlying execution environment (vendor dependent); or place state information into the message. Unfortunately, Web Services offer no standard way of accomplishing the latter task, requiring SOA teams to customize their SOAP headers—which is usually a deal killer.

The SPEAR approach, however, includes state information in the message, because, of course, the message is the document. As a result, they are taking a fully Service-oriented approach to maintaining state. They are able to do so in spite of leveraging an ESB because they selected the Fiorano ESB, which has long maintained state in a fully message-centric manner, instead of spawning threads to keep track of state as in other vendors’ ESBs.

Asynchronicity as the General Case
For many years, Gartner believed that SOA interactions were inherently synchronous, request/response—casting SOA as little more than next-gen client/server—until TIBCO twisted their arm into admitting that yes, SOA could be event driven. Nevertheless, SOA has always allowed for asynchronous as well as synchronous Service exchange patterns. (The whole Gartner event-driven SOA kerfuffle led to the SOA 2.0 fiasco, lest we forget.) In fact, ZapThink pointed out the importance of asynchronous behavior as early as 2002.

In the SPEAR architecture, the listener acts as the handler, retaining messages at their last stop. The senders simply fire and forget. Messages are sent to the Fiorano bus, not the destination, allowing for dynamic routing of messages as well as publish/subscribe. In this way the ESB routes, filters, and enforces policy via the URIs themselves.

Publish/subscribe is a broadcast push exchange pattern: many consumers can subscribe to the same topic, and the ESB pushes messages to subscribers as appropriate. Even when a single consumer queries a resource, the ESB follows a push pattern, putting documents onto a queue for the consumer to pick up. As a result, SPEAR can support different consumer behaviors, depending upon the use case. If the consumer is accessing Services via unreliable network connections, or simply requires low message volumes and can tolerate some latency, then the consumer can simply poll the Service. In other cases, when latency is an issue or when there are higher message volumes, the ESB can perform a true push to the consumer via a JMS interface.

OK, hold on just one minute. JMS? I thought we were talking about REST, you know, over HTTP. How can JMS fit into this picture?

Yes, the USCG is being iconoclastic once again. The ESB is abstracting the endpoint, while at the same time providing a push-based messaging infrastructure. If the consumer wants the resource to push a real-time stream of large messages to it, then the URI should resolve to a JMS endpoint. If not, or if the consumer doesn’t support JMS (typically when it’s running over HTTP) then the resource will resolve to an HTTP endpoint.

The ZapThink Take
Is the USCG implementing “pure” SOA or “pure” REST? I’m not even going to dignify those questions with a response, because the whole notion of a “pure” architectural approach is inherently dogmatic. What the USCG has done is implement an architecture that actually works for them—that is, it delivers loosely coupled, abstracted Business Services with the flexibility and performance they require. And remember, actually working trumps following a pre-determined set of best practices every time—especially when those best practices don’t actually solve the problems at hand.

There are two important morals here. First, REST-based SOA is alive and well, and offers straightforward solutions to many of the knottier problems that Web Services-based SOA has suffered from. But even more importantly, the success the USCG has achieved shows that any architectural approach is nothing more than a loose collection of best practices. It’s up to the architect to know which best practices are best for solving their particular problems. Avoid a dogmatic approach, and select the right tool for the job, even if that brands you as an iconoclast.


More Stories By Jason Bloomberg

Jason Bloomberg is the leading expert on architecting agility for the enterprise. As president of Intellyx, Mr. Bloomberg brings his years of thought leadership in the areas of Cloud Computing, Enterprise Architecture, and Service-Oriented Architecture to a global clientele of business executives, architects, software vendors, and Cloud service providers looking to achieve technology-enabled business agility across their organizations and for their customers. His latest book, The Agile Architecture Revolution (John Wiley & Sons, 2013), sets the stage for Mr. Bloomberg’s groundbreaking Agile Architecture vision.

Mr. Bloomberg is perhaps best known for his twelve years at ZapThink, where he created and delivered the Licensed ZapThink Architect (LZA) SOA course and associated credential, certifying over 1,700 professionals worldwide. He is one of the original Managing Partners of ZapThink LLC, the leading SOA advisory and analysis firm, which was acquired by Dovel Technologies in 2011. He now runs the successor to the LZA program, the Bloomberg Agile Architecture Course, around the world.

Mr. Bloomberg is a frequent conference speaker and prolific writer. He has published over 500 articles, spoken at over 300 conferences, Webinars, and other events, and has been quoted in the press over 1,400 times as the leading expert on agile approaches to architecture in the enterprise.

Mr. Bloomberg’s previous book, Service Orient or Be Doomed! How Service Orientation Will Change Your Business (John Wiley & Sons, 2006, coauthored with Ron Schmelzer), is recognized as the leading business book on Service Orientation. He also co-authored the books XML and Web Services Unleashed (SAMS Publishing, 2002), and Web Page Scripting Techniques (Hayden Books, 1996).

Prior to ZapThink, Mr. Bloomberg built a diverse background in eBusiness technology management and industry analysis, including serving as a senior analyst in IDC’s eBusiness Advisory group, as well as holding eBusiness management positions at USWeb/CKS (later marchFIRST) and WaveBend Solutions (now Hitachi Consulting).

@MicroservicesExpo Stories
Puppet Labs has announced the next major update to its flagship product: Puppet Enterprise 2015.2. This release includes new features providing DevOps teams with clarity, simplicity and additional management capabilities, including an all-new user interface, an interactive graph for visualizing infrastructure code, a new unified agent and broader infrastructure support.
It’s been proven time and time again that in tech, diversity drives greater innovation, better team productivity and greater profits and market share. So what can we do in our DevOps teams to embrace diversity and help transform the culture of development and operations into a true “DevOps” team? In her session at DevOps Summit, Stefana Muller, Director, Product Management – Continuous Delivery at CA Technologies, answered that question citing examples, showing how to create opportunities for ...
Early in my DevOps Journey, I was introduced to a book of great significance circulating within the Web Operations industry titled The Phoenix Project. (You can read our review of Gene’s book, if interested.) Written as a novel and loosely based on many of the same principles explored in The Goal, this book has been read and referenced by many who have adopted DevOps into their continuous improvement and software delivery processes around the world. As I began planning my travel schedule last...
Any Ops team trying to support a company in today’s cloud-connected world knows that a new way of thinking is required – one just as dramatic than the shift from Ops to DevOps. The diversity of modern operations requires teams to focus their impact on breadth vs. depth. In his session at DevOps Summit, Adam Serediuk, Director of Operations at xMatters, Inc., will discuss the strategic requirements of evolving from Ops to DevOps, and why modern Operations has begun leveraging the “NoOps” approa...
Microservice architecture is fast becoming a go-to solution for enterprise applications, but it's not always easy to make the transition from an established, monolithic infrastructure. Lightweight and loosely coupled, building a set of microservices is arguably more difficult than building a monolithic application. However, once established, microservices offer a series of advantages over traditional architectures as deployment times become shorter and iterating becomes easier.
SYS-CON Events announced today that DataClear Inc. will exhibit at the 17th International Cloud Expo®, which will take place on November 3–5, 2015, at the Santa Clara Convention Center in Santa Clara, CA. The DataClear ‘BlackBox’ is the only solution that moves your PC, browsing and data out of the United States and away from prying (and spying) eyes. Its solution automatically builds you a clean, on-demand, virus free, new virtual cloud based PC outside of the United States, and wipes it clean...
In his session at 17th Cloud Expo, Ernest Mueller, Product Manager at Idera, will explain the best practices and lessons learned for tracking and optimizing costs while delivering a cloud-hosted service. He will describe a DevOps approach where the applications and systems work together to track usage, model costs in a granular fashion, and make smart decisions at runtime to minimize costs. The trickier parts covered include triggering off the right metrics; balancing resilience and redundancy ...
SYS-CON Events announced today that G2G3 will exhibit at SYS-CON's @DevOpsSummit Silicon Valley, which will take place on November 3–5, 2015, at the Santa Clara Convention Center in Santa Clara, CA. Based on a collective appreciation for user experience, design, and technology, G2G3 is uniquely qualified and motivated to redefine how organizations and people engage in an increasingly digital world.
SYS-CON Events announced today that HPM Networks will exhibit at the 17th International Cloud Expo®, which will take place on November 3–5, 2015, at the Santa Clara Convention Center in Santa Clara, CA. For 20 years, HPM Networks has been integrating technology solutions that solve complex business challenges. HPM Networks has designed solutions for both SMB and enterprise customers throughout the San Francisco Bay Area.
Whether you like it or not, DevOps is on track for a remarkable alliance with security. The SEC didn’t approve the merger. And your boss hasn’t heard anything about it. Yet, this unruly triumvirate will soon dominate and deliver DevSecOps faster, cheaper, better, and on an unprecedented scale. In his session at DevOps Summit, Frank Bunger, VP of Customer Success at ScriptRock, will discuss how this cathartic moment will propel the DevOps movement from such stuff as dreams are made on to a prac...
SYS-CON Events announced today that Pythian, a global IT services company specializing in helping companies leverage disruptive technologies to optimize revenue-generating systems, has been named “Bronze Sponsor” of SYS-CON's 17th Cloud Expo, which will take place on November 3–5, 2015, at the Santa Clara Convention Center in Santa Clara, CA. Founded in 1997, Pythian is a global IT services company that helps companies compete by adopting disruptive technologies such as cloud, Big Data, advance...
The pricing of tools or licenses for log aggregation can have a significant effect on organizational culture and the collaboration between Dev and Ops teams. Modern tools for log aggregation (of which Logentries is one example) can be hugely enabling for DevOps approaches to building and operating business-critical software systems. However, the pricing of an aggregated logging solution can affect the adoption of modern logging techniques, as well as organizational capabilities and cross-team ...
Culture is the most important ingredient of DevOps. The challenge for most organizations is defining and communicating a vision of beneficial DevOps culture for their organizations, and then facilitating the changes needed to achieve that. Often this comes down to an ability to provide true leadership. As a CIO, are your direct reports IT managers or are they IT leaders? The hard truth is that many IT managers have risen through the ranks based on their technical skills, not their leadership ab...
In today's digital world, change is the one constant. Disruptive innovations like cloud, mobility, social media, and the Internet of Things have reshaped the market and set new standards in customer expectations. To remain competitive, businesses must tap the potential of emerging technologies and markets through the rapid release of new products and services. However, the rigid and siloed structures of traditional IT platforms and processes are slowing them down – resulting in lengthy delivery ...
Several years ago, I was a developer in a travel reservation aggregator. Our mission was to pull flight and hotel data from a bunch of cryptic reservation platforms, and provide it to other companies via an API library - for a fee. That was before companies like Expedia standardized such things. We started with simple methods like getFlightLeg() or addPassengerName(), each performing a small, well-understood function. But our customers wanted bigger, more encompassing services that would "do ...
Docker containerization is increasingly being used in production environments. How can these environments best be monitored? Monitoring Docker containers as if they are lightweight virtual machines (i.e., monitoring the host from within the container), with all the common metrics that can be captured from an operating system, is an insufficient approach. Docker containers can’t be treated as lightweight virtual machines; they must be treated as what they are: isolated processes running on hosts....
SYS-CON Events announced today the Containers & Microservices Bootcamp, being held November 3-4, 2015, in conjunction with 17th Cloud Expo, @ThingsExpo, and @DevOpsSummit at the Santa Clara Convention Center in Santa Clara, CA. This is your chance to get started with the latest technology in the industry. Combined with real-world scenarios and use cases, the Containers and Microservices Bootcamp, led by Janakiram MSV, a Microsoft Regional Director, will include presentations as well as hands-on...
DevOps has traditionally played important roles in development and IT operations, but the practice is quickly becoming core to other business functions such as customer success, business intelligence, and marketing analytics. Modern marketers today are driven by data and rely on many different analytics tools. They need DevOps engineers in general and server log data specifically to do their jobs well. Here’s why: Server log files contain the only data that is completely full and accurate in th...
Skeuomorphism usually means retaining existing design cues in something new that doesn’t actually need them. However, the concept of skeuomorphism can be thought of as relating more broadly to applying existing patterns to new technologies that, in fact, cry out for new approaches. In his session at DevOps Summit, Gordon Haff, Senior Cloud Strategy Marketing and Evangelism Manager at Red Hat, discussed why containers should be paired with new architectural practices such as microservices rathe...
What does “big enough” mean? It’s sometimes useful to argue by reductio ad absurdum. Hello, world doesn’t need to be broken down into smaller services. At the other extreme, building a monolithic enterprise resource planning (ERP) system is just asking for trouble: it’s too big, and it needs to be decomposed.