Chapter 10. SOA vs. the world
In this chapter
- Constraints of REST
- SOA and the cloud
- SOA and big data
In this part of the book, we’ve looked at antipatterns, discussing some of the things that can go wrong, and we’ve looked at a case study, exploring how different patterns can interact with and complement each other. This chapter takes a look at the impact of other architectural styles and trends on SOA. We’re going to cover:
- REST—What is the relationship between REST and SOA? Are they friends? Foes? Can they work together?
- Cloud—Is SOA a good fit for cloud-based deployments? How does the cloud affect SOA?
- Big data—NoSQL is starting to mature, with offerings from the big vendors both in the advanced analytics front (IBM and EMC offer distributions of Hadoop; Microsoft, Oracle, and others provide Hadoop integration) as well as solutions for big data in real time (such as IBM InfoSphere Streams and SAP HANA). How does SOA fit in?
Let’s start by looking at the REST architectural style, which many see as an alternative to SOA.
This makes mashups sound a little like SOA, so to help clarify things I’ll explain the differences between REST and SOA and what a RESTful SOA is. But first, let’s look at what exactly REST is.
In recent years, the REST architectural style has become very popular, with a lot of companies building RESTful APIs (such as Twitter and Facebook) and a lot of other companies building value-added services, called mashups, by using these APIs.
Wikipedia defines mashups as:
Cloud computing is an important IT trend, taking virtualization to the next level by using a large pool of virtualized hardware to provide utility computing capabilities. It provides an electricity-like model, where computational resources are available on demand (usually with pay-as-you-go billing) and with the ability to elastically grow and shrink your resource use as needed.
We’ll take a look at how this relatively new playground affects SOA, but let’s first try to make sense of the different cloud-related terms out there.
Most research organizations (like TDWI or Forrester Research) agree that big data evolves around different Vs, like velocity, volume, variety, and variability. Personally, I think the major drivers are just the first two Vs—the velocity at which you have to ingest data, along with the latency until it’s usable, and the total volume of data you have to store and do something with. If you have a high peak load of messages for a couple of hours a day, and you don’t need to see that data until a day later—that’s not a big data problem. The same goes for terabytes of archival data you don’t need to analyze, and are just storing for some regulatory reason.
Big data has a lot of implications, starting with changing the way we think about data and producing new professions like data science. It also has technical implications, which is what we’ll take a look at next.
There are, of course, other architectural styles and technologies that are related to SOA. We discussed event-driven architecture (EDA) and SOA as part of the Inversion of Communications pattern in chapter 5. Another relevant style is domain-driven design, which isn’t as popular as the three trends discussed in this chapter, but it can complement SOA as a way to design individual services.
The focus of this book, is on using SOA as a way to solve distributed systems challenges, so naturally this chapter’s coverage of other architectural styles only scratched the surface. You can take a look at the next section for resources that will expand on the topics mentioned here.
Jothy Rosenberg and Arthur Mateos, The Cloud at Your Service: The When, How, and Why of Enterprise Cloud Computing (Manning, 2010). Jothy’s and Arthur’s book provides a good all-round introduction to cloud concepts and technologies.
Peter Deutsch, “The Eight Fallacies of Distributed Computing,” http://blogs.oracle.com/jag/resource/Fallacies.html. James Gosling (the father of Java) concisely lists Peter Deutsch’s eight fallacies on his blog.