With the service-oriented architecture (SOA) community recently issuing its SOA Manifesto (based closely it seems on the largely excellent example of the Agile Manifesto), I have been thinking recently about whether we need such a document for Web-oriented architecture, also known as WOA. The manifesto format can be a useful tool for creating critical mass around and focus on an important new idea or approach. I don't believe, however, that we need one for everything that comes out; only when important new advancements are still in need of clear explanation. So while the reception was decidedly mixed for the SOA Manifesto, by-and-large I do think such efforts can create useful statements of principles that get people thinking about the fundamentals and underlying truths of their work and help in creating a shared understanding.
The challenge with broad declarative statements like a manifesto is that technical communities are by definition consist of technical people. Such people are typically deeply experienced with formal intellectual appraisal and are famously independent thinkers who in my experience generally respect open debate and discussion. But they will almost automatically resist when ideas appear to be predigested for them and then presented on a platter. This is particularly the case if a hidden agenda or conflict of interest is perceived. Thus, the manifesto approach is a useful one most often when it's created through a collaborative effort and with concepts that have previous been subject to widespread discussion. It is less effective when it's used to distribute propaganda or tied in with motives that are unclear. In other words, it shouldn't be done lightly.
So I debated at length over the last few months whether WOA actually needs a manifesto. In the end, for reasons that I explain below, I finally concluded that it does, just not in the traditional way. I'm calling the output of this new approach an "unmanifesto". You'll find the 17 principles of the WOA Unmanifesto listed at the bottom of this post, each of which will be explored in more detail in upcoming posts.
Skip straight to the principles of the WOA Unmanifesto
Backstory on the evolution of WOA
Personally, I've been fortunate to spill quite a bit of fairly popular digital ink on the subject of WOA over the last few years. I did this because I felt information availability on the topic was fairly poor despite the central importance of the concept to most efforts involving software architecture these days, either on the Internet or in the enterprise.
Of course, Gartner's Nick Gall is the man most directly responsible (to paraphrase a line from a great sci-fi film) for creating the initial concept of WOA. I was fortunate to meet him present personally at an enterprise architecture summit many years ago now and see him present the concepts. I was captivated at the time and I remain captivated by WOA today. Since then, I've been fortunate to help carry the banner and put my own spin on what I think WOA is and where it's going. I've not had as much time to sit down and compare notes as much as I'd like with Nick and other great REST/WOA thinkers like Roy Fielding, Sam Ruby, Tim Bray, and literally hundreds of others that I must leave out for brevity. This is an attempt to start that discussion in earnest since WOA is clearly a growing influence on a great many aspects of software architecture today.
But ensuring we have a broad understanding about what WOA is part of the problem. My premise from the beginning has been that we can use the example of the Web itself to extract enormously important lessons about Web architecture if we are willing to learn what it has to teach us. WOA at its core is based firmly on REST principles, but that's only the beginning since the Web continues to evolve rapidly and we've seen important patterns and additions emerging such as mashups as well as OpenID and OAuth, to name but three major developments. But as I've covered in the past, while REST is the canonical basis for building Web-based software when it comes to moving data around the network, we still need a bigger conceptual umbrella to capture the higher order architectural advancements in Web software (i.e. those building on REST) . This broader set of essential patterns and concepts is one that has co-evolved with REST and the Web (including distribution, composition, security approaches, data models, data portability, and so on) over the years. WOA is that umbrella.
WOA is more than REST or ROA
Though the underpinning is REST, WOA is therefore a superset of resource-oriented architecture (ROA) and contains all the moving parts we'd find in an architecture: 1) the basic elements of resource-based architecture, 2) the glue the binds them (HTTP transfer is the core one, but there are refinements now, e.g. ATOM and JSON feeds between browser widgets for example), 3) consumption models (how browsers and other clients fit in, mashups, recognizing OAuth as a first-class citizen in Web architecture, etc.), and the patterns that connect them all together.
First, though, to get perspective on all this and to help us decide what's really in WOA and what's not -- something that I've tried to do for several years now -- we have to define some generally agreed-upon principles to give us a set of objective discriminators. Let's not forget that the Web is one of the most effective systems for connecting people, information, and software yet created. It has profound and fundamental properties that are enormously powerful when understood and used effectively. These can be fully unleashed when architectural principles are followed that are aligned with the Web's fundamental nature. Fortunately for us, many of these principles have been discovered or developed over the last 16 years or so of the Web. Tragically, they are as not well known as they should be. Part of the reason for this is that the Web itself is an emergent, bottom-up phenomenon and it's not always easy to see what's happening on a wide scale. This bottom-up state of affairs has held back the development of the Web to the extent that most people don't realize that WOA, by definition, is the dominant software architectural model in the world today. It's what's being used today and is what works most effectively, most naturally, and most easily when it comes to the overall design of Web-based systems.
But "effective", "natural", and "easily" are subjective terms. How can we get more specific about defining WOA? Can we reach a genuinely accepted common understanding that would allow us to decide if a software system that we encountered did or did not use WOA concepts? Most importantly, how do we look at new innovations in Web architecture and decide if they are part of WOA or not? There needs to be a dividing line. Something like a manifesto might help.
What's an "un-manifesto"?
To create this dividing line, I am issuing something I'm calling here an "unmanifesto." A manifesto developed by a single person is by nature of limited value, since it should instead reflect some wider conversation that represents a broader, community-validated understanding. Like an unconference, where the contents of the agenda are arrived at by a collaborative process and the attendees are also presenters, an unmanifesto is a distributed one in which there is more than one voice and the statements are made in public, online via social media. I call it an "un-manifesto" because it's not a manifesto, it's just the start of an important conversation by making some specific statements. An "unmanifesto" is an open, online discussion where it's assumed that there are multiple points of view. Anyone can join in and no one is excluded. Sound confusing? It is a bit messier than a traditional manifesto but it's also far richer and more open. If you care about modern Web architecture, I hope you will join me in this effort.
Thus, the principles below represent my WOA unmanifesto. There may be other WOA unmanifestos. This one will evolve over time as we learn more. Of course, anyone may issue their own WOA unmanifesto and anyone may comment and critique the ones that are created. The best ideas will be debated, survive, and be replicated. The ideas that aren't good just won't last. Eventually, after a distributed and open discussion, clarity will be achieved. Of course, this will only work if a community exists that is interested in the topic and is willing to actually listen to each other. I hope there is and that we will.
The Web-Oriented Architecture (WOA) Unmanifesto
The principles are broken down into four major groups: Resource-Orientation, Performance and Consumption, Interaction and Composition, and Openness and Security.
I. WOA Is Based on a Resource-Oriented Hypermedia Data Architecture
Principle #1: The fundamental artifact and unit of value in WOA is data stored as uniquely identified Web resources on the network with a uniform interface based on REST.
Principle #2: Web resources are maintained in a hyperlinked fabric using hypermedia (content with non-linearly navigable embedded links). In general, URIs should favor granularity and depth in linkage instead of being monolithic.
Principle #3: Resources and their network addresses (URIs) are self-descriptive so that WOA clients can determine how to consume them. In general, a URI should indicate what data format is being used and indicate nested elements with URL segmentation.
Principle #4: All application data is therefore accessible as resources in the manner presented here. Resources are visible on the network to authorized WOA clients, where sharing to all is the default should be the default whenever possible. Note: The major implication of this, particularly for legacy environments (enterprises) is that all existing databases and other datasets should be mapped to the resource model described here via REST. Even servers, storage, and network infrastructure are considered resources as they increasingly are in cloud computing APIs today (see OCCI).
Principle #5: Thus, resource-orientation is the best way known to 1) create a loosely-coupled, participative and shared global architecture that 2) can scale almost infinitely, 3) be used by virtually any platform or client, 4) directly facilitates information discovery (by analyzing link structure), 5) be easily recombined, and last (not least) 6) builds value non-linearly in the form of network effects.
II. Performance and Consumption: First-Class Citizens of WOA
Principle #6: Web resources must be stateless, layered, and cacheable, as per REST.
Principle #7: Network consumption of resources (transfers) is inversely proportional to how complex a Web resource is; i.e. the simpler the structure and data of a resource is, the more likely it will be used, recombined, and perform well. See the Services Continuum discussion for more background.
Principle #8: Resources should organized to optimize their discovery and reuse. This principle has many more implications that it sounds like at first. Not only should resources be SEO-friendly but it must be recognized that they are also APIs that support applications elsewhere on the network. Optimization for the latter can mean licensing agreements, SLAs, and customer support and all the trappings and requirements of open APIs.
III. The Structure of the Web for Application Architecture and Value Creation: Interaction and Composition
Principle #9: A resource is recognized as having a higher realized value (network effects) the more that other parts of the network link to it.
Principle #10: Copying of resources is discouraged: The network effect of Web resources is increased when they are linked to from other Web resources instead of replicated. Caching is encouraged however, as long as it's at the same URI.
Principle #11: WOA clients provide value by connecting to the network to view, interact with, operate on, and recombine resources from multiple sources using REST. Note: The browser is the canonical Web client. There are many other types of clients.
Principle #12: Observable value is increased when resources from simultaneous multiple domains are accessed by WOA clients (mashups) which are themselves resources (self-contained applications).
Principle #13: Self-distributing applications create additional network effects. Native WOA clients can be distributed as resources (code-on-demand) that are self-contained applications (such as AJAX, Flash applications, widgets, etc.) to be embedded in elements of other WOA clients. This increases in turn the value that the resources the WOA clients use.
Principle #14: WOA applications inherently encourage link propagation, both in the resource fabric and out-of-band, through syndication, widgets, badges, mashable components, open APIs, and any other method that invokes Jakob's Law.
IV. Openness is Balanced with Security
Principle #15: Resources are in formats that are based on open, published descriptions and standards. Resources must be readily consumable from the canonical WOA client.
Principle #16: Resources can be secured with HTTPS, WebDAV, OpenID, digital signatures, etc. Locally defined user ID and passwords are permitted but discouraged as are proprietary (i.e. not open standards-based) security approaches.
Principle #17: Resources that are secured must be exposed to WOA clients by a safe 3rd party authorization method. OAuth is preferred.
These 17 principles represent a significant update to my original definition, which remains widely cited. WOA has evolved and our description of it must evolve with it. Please note that I have pushed some details down into the description of the principles, which will be forthcoming soon.
I hope you see how there is more to WOA than just REST and that there are clearly higher order principles around composition and distribution architectures that need more definition. On the composition side, for example, incorporating Michael Ogrinz's mashup patterns may be a good way to access best practices and eliminate duplication. I'll be exploring that as well as other sources of high value inputs as this unmanifesto evolves. Keeping the principles clean, well-organized, and at the same level of abstraction will important and I'll do my best to achieve that. Also, I'll be clear that I still firmly believe that SOA itself is largely headed in an WOA direction, it'll just take a while given the momentum and vendor history in that space. So the WOA Unmanifesto is just as relevant and applicable to the SOA world as the Web world.
Finally, there are many essential details and implications for each of these principles, which were not included here lightly; each and every one is a key aspect of Web-oriented architecture. I also realize that for these principles to be broadly understood and themselves consumable by most Web architecture, each and everyone one of these principles needs a detailed breakdown with examples. This is one of the big problems with WOA being an emergent architectural style and not a standard in itself.
Over the coming months, as often as I am able, I will be breaking down each of these components as we begin discussing them here. Input and feedback is very welcome and encouraged both in comments below and posts (these are preferred) and by e-mail (mine is dion@hinchcliffeandco.com) only if necessary. Also, I'm reserving the right to tweak this for a few more days to make sure the wording on the principles reflects my intent. I'll put a change log below to make sure nothing is lost.
Please join in the WOA Unmanifesto discussion below. I will respond as often as I can.
Further Reading:
What Is WOA? It's The Future of Service-Oriented Architecture (SOA)
Where Is The Future of SOA Headed? Where The Web Goes...
Unboxing Web-Oriented Architecture: The 6 Aspects Of An Emergent Architectural Style
Web 2.0 success stories driving WOA and informing SOA
The SOA world begins considering Web-Oriented Architecture (WOA) in earnest