A software architecture is an abstraction of the run-time elements of a software system during some phase of its operation. A system may be composed of many levels of abstraction and many phases of operation, each with its own software architecture.

Let’s start with a simple (yet surprisingly complex) example. My blog is a network-based application — a specific grouping of functionality and behavior that allows me to accomplish a desired task using multiple computers that communicate via a network. That’s what application means in our industry: applying computing to accomplish a given task.

The implementation of my blog consists of, at the time of this writing, an installation of Apache HTTP Server 2.0.61 that is executing PHP 5.2.3 in order to run the scripts from Wordpress 2.3.3 which use sockets to interact with another server running MySQL 5.0 in order to store, manipulate, and retrieve database entries that form the content of my blog when passed through various template scripts and delivered to any number of specific versions of Web-based clients, usually via HTTP, many of which apply stylesheets prior to rendering said content in a form that is (hopefully) readable by you. Phew! And that’s just the Web interface. Wordpress has at least four other interfaces that are not Web-based, and each has its own set of network or server-side clients with their own specific versions, and the sum of all of these individual components make up the implementation of what I call Untangled.

Note that some of this blog’s implementation (the clients used by other readers) is not under my control. The vast majority of it, in fact, regardless of whether we count in lines of code or software installs. If you don’t think the clients should be considered part of the implementation, then think again: all this effort would be wasted if the words can’t be read.

Within my blog implementation there are many software architectures. A huge number of architectures, in fact, at various levels of abstraction and component granularity. I could probably spend months trying to describe them all and would still miss a few valid abstractions. If we limit ourselves to just the network-based architectures (the ones where component interaction is limited to message exchange), then we might just have a chance to discuss them in a week. However, just one example should be enough to get the idea, and the Atom publishing mechanism within Wordpress is ideally suited for our purpose.

Atom is a great example of how architectures are often nested within other architectures. Using typed links (hypertext), a couple XML media types, and a subset of HTTP, Atom defines a range of expected behaviors and interactions for the purpose of authoring blog entries and syndicating feeds. The Atom implementation within my blog consists of the various Web browsers and Atom clients out on the Internet (which are thankfully pretty consistent at the moment) and a couple scripts, utility functions, and links within the theme headers of my Wordpress installation. Compare that to the Atom architecture within my blog, which consists of just the externally observable behavioral abstraction: clients that consume or produce the atom formats, send AtomPub request messages, and receive AtomPub responses; a server that identifies and provides specific resources that accept HTTP requests, stores entries, and responds in accordance with the Atom protocols.

Note that when we talk about the implementation of my blog versus an architecture of my blog, we are still talking about the same software — the only difference between the two is the amount of extraneous detail being ignored. Of course, another advantage of the architecture view is that we can talk about the interactions independent of the specific implementations, and thus find common ground in which to standardize the interactions in the form of an application-level protocol. It is also easier to perceive systemic effects at the higher architectural levels (architectural properties, such as evolvability, that encompass many implementations over time).

So, where do software architectural styles fit within this scheme?

Representational State Transfer (REST) is a software architectural style, not a software architecture. REST is just one of many software architectural styles. Specifically, REST is a named set of constraints on component interaction that, when obeyed, cause the resulting architecture to have certain properties (preferably, desirable properties). Like software patterns, an architectural style packages a set of constraints under a convenient name and tells us about the properties that are induced by those constraints when we follow the style. There are some subtle differences between architectural patterns and architectural styles, mainly due to the different audiences/communities, but they are equivalent from the point of view of an architect of network-based software.

We can talk about architectural styles as an abstraction in general. We can also talk about the architectural styles found within specific architectures, such as the Web architecture as a whole, or within the Atom publishing protocols as standardized, or even the architecture observed by abstracting a specific implementation of WordPress. We can compare different architectures that perform the same function, along with the different styles found within those architectures, in terms of their architectural properties. Furthermore, we can talk about how a given implementation matches (or fails to match) an intended architecture that is supposed be an example of a given style.

Discussion of software architecture therefore falls into the same tracks that we often hear when real-world architects talk about the architecture of buildings. They might have discussions about the Doric style, compare examples of that style found within various architectures, or just admire the Parthenon. Likewise, different styles that perform the same function can be compared, as can slight differences in the specific implementations that are used as examples of a given style.

Architecture is therefore an abstraction of implementation, and styles are the named patterns by which we can understand architectures and architectural design. Simple, right?

Then why is it that SOA advocates insist on comparing REST to specific implementations and then complain about how vague the style is compared to the implementation? ROA is not REST. ROA is supposed to be a kind of design method for RESTful services, apparently, but most folks who use the term are talking about REST without the hypertext constraint. In other words, not RESTful at all. REST without the hypertext constraint is like pipe-and-filter without the pipes: completely useless because it no longer induces any interesting properties. The RESTful Web Services book doesn’t help the situation by renaming the hypertext engine as connectedness. That does nothing but obscure its role as the driving force in RESTful applications.

Linda is another example of oddly construed comparisons with REST, though in this case it is generally abused by REST advocates. Mark Baker was the first to notice the similarity between Linda’s uniform interface and the uniform interface constraints within REST. However, Linda is not a style — it is an architecture for coordination via a shared tuplespace (an example of the blackboard architectural style). It makes sense to compare REST to the blackboard style (they do have a lot in common, as styles go). Likewise, there are some limited comparisons that can be made between Linda and the Web architecture, but one must keep in mind that they serve completely different functions (Linda being a coordination language and the Web being a distributed hypermedia system). But to make any comparison at all between REST (a style) and Linda (an architecture designed to support a different style in order to accomplish an entirely different function) is absurd; just as absurd as trying to compare the Doric style to my condo’s garage door opener. Unlike Mark, some REST advocates have a tendency to lose track of when they are talking about REST versus when they are talking about Web architecture versus when they are talking about specific implementations that attempt to match the Web architecture.

In summary:

1. Web implementation consists of the current universe of information identified by URIs and all of the specific versions of software currently operating within that information space (like Safari, Firefox, Apache httpd, Wordpress, …).
2. Web architecture consists of the protocols and data formats that define the syntax and semantics of interactions between Web components: the standards for URI, HTTP, HTML, XML, and many others. All of these standards are designed to optimize RESTful interaction, with varying degrees of success, but not to require such interaction because RESTful interaction is not the only way they are used.
3. REST is an architectural style that, when followed, allows components to carry out their functions in a way that maximizes the most important architectural properties of a multi-organizational, network-based information system. In particular, it maximizes the growth of identified information within that system, which increases the utility of the system as a whole.

Web implementations are not equivalent to Web architecture and Web architecture is not equivalent to the REST style. REST constraints do not constrain Web architecture — they constrain RESTful architectures (including those found within the Web architecture) that voluntarily wish to be so constrained. HTTP/1.1 was designed to enable and improve RESTful architectures, just as REST was designed to reflect and explain all of the best things about Web architecture. That does not mean that HTTP/1.1 is constrained to a single style; it means those other styles are not part of the design (i.e., we don’t care if future changes to HTTP will cause them to break). Only some of the architectures found on the Web are RESTful, but that doesn’t change the fact that RESTful architectures do work better on the Web than any other known styles. They work better because REST induces the architectural properties that the Web needs most — reusability, anarchic scalability, evolvability, and synergistic growth — and thus the Web architecture has been updated over time to promote RESTful styles over all others, by design.

I’ve been vaguely following this discussion on the W3C TAG mailing list for some time and, against my better judgement, I feel a need to comment on the suggestions. Actually, that’s not quite right, since I really don’t have any polite comments to make on the suggestions, and I wouldn’t want to offend my friends on the TAG.

Instead, I’ll just ask a few questions about this one sentence:

A key requirement of the Semantic Web is that URIs be used
to identify resources unambiguously.

Why?

• What makes that a key requirement of the Semantic Web?
• What makes the TAG think it is feasible to satisfy that requirement?
• How will the TAG know when the requirement is (or isn’t) satisfied?
• If someone can show that this requirement is inherently unsatisfiable, doesn’t that imply the Semantic Web will never happen?

Or, is it not a requirement, and all these proposals are just an excuse to avoid designing a Semantic Web that would actually work within the same problem space of the current Web?

I don’t want the Web to constrain what people do: the Web
is not there to constrain society. It’s there to model society
in its completeness, in its entirety. [Tim Berners-Lee, 1994]

Have we forgotten why?

On the Web, millions of people mint URIs, and millions more use them in references. Millions of human beings, conversing over time, with an occasional URI thrown in to refer to a subject under discussion.

When was the last time you had an unambiguous discussion?

For traditional media, an event that happened last week would be old news by now. After my message, I received a bunch of warm regrets from folks I know in the community, a collection of thanks from people who were just glad someone did something, and no formal reaction from anyone. No news coverage, no public apologies, and not even the sense that anything would change. There were a few blog mentions from people outside the community (Emily Ratliff on the 14th, rippling to Michael Dolan on the 15th, which in turn rippled to Jim Grisanzio on the 17th), but nobody asked me for further comments. That was last week.

This week, the traditional side of non-traditional media reporting went back to work (on Tuesday, actually, due to the three-day weekend for President’s day that some companies observe). It started on the 20th with a 9am email message from IDG asking for comment on my resignation, which the reporter had discovered while “looking through some Sun blogs.” The problem with spin control is that sometimes you spin up a larger storm than the one being controlled. That’s six full days after the event (five days after traditional media would have ignored the story as old news).

Unfortunately, I was stuck in the lobby of an Acura dealership waiting for my car, reading the 500 or so email messages I downloaded just before 9am, and did not get back to him in time even if I had wanted to add something (I didn’t). Naturally, Sun’s very competent PR team are never caught without something to say, and Terri’s response was polite with only the tiniest amount of spin. ["consultant" ... WTF? I get paid for consulting. The only thing Sun provided me is travel expenses for two face-to-face meetings and one keynote talk in Berlin. Day paid all of my other costs. There is a huge difference between being a member of the community (an advisor) and being a consultant, even if the original invitation to join the OpenSolaris CAB came from Sun. Sun certainly didn't refer to me as a consultant when they bragged about that in the press. If Sun wants to call me a consultant, maybe Day should send a bill for my hourly rate.]

To close the door on that article, IDG turned to an “industry analyst” from Redmonk. Stephen O’Grady, who does happen to be one of Sun’s consultants (in a refreshingly open way), tossed a little water on the embers of my resignation. He later rippled on the larger conversation as well, in a fairly balanced piece. Entirely accurate points on their own, yet entirely missing my point. Sun is running into trouble because it has a problem with honesty and with ethical behavior within a community setting, and you can’t blame that on anyone else (especially not the critics). What is the point of creating the OpenSolaris Community governance if the community isn’t even allowed to decide what is called OpenSolaris? This isn’t an abstract discussion of trademarks. It is the fundamental basis for making technical decisions of any kind for the project.

Sun made a commitment to open development with the OpenSolaris Charter. Sun does have the legal right to take advantage of its own trademarks, which is precisely what they had been doing for the past three years, in the press, by taking advantage of the positive spin regarding open development. Sun is fully capable of changing that decision by amending or dissolving the charter, but instead has chosen to ignore the governance model while at the same time claiming the open development manta as their own. I cannot support that. Sun was using my name as “proof” that they were listening to the open development community, so I had to go.

The issue is really quite simple: Sun wants to have your cake and eat it too.

In contrast, the MySQL model is open source, not open development. I respect that because they are honest about it, not just because the result is published as open source. There is even a MySQL user community, providing input to the company without any illusion that they are helping to develop the main product.

I am not a free software zealot. For me, open source is a business decision, not a religion. In my opinion, an open development model results in better source code, but that’s just one of many aspects that can improve or reduce software product quality. For example, Day Software developers participate in open development at Apache for almost all of our infrastructure software, which we then use as components within our not-entirely-open-source content management products. We learn from that open development experience, every day, and it influences all of the products that we develop. Each of our developers are better developers because they participate in open development, and that in turn has encouraged more great open source developers to work for Day. It isn’t just about the code.

In any case, the IDG article showed up in the evening of the 20th, in an InfoWorld blog, and then spread from there to several outlets. Boom! A rock has been heaved into the pond, and more ripples go forth. I’ve had four google alerts already today and it’s barely past noon. We’ve got bloggers who are blogging about blogs that comment on other blogs that discuss a blog that referenced an email message that I wrote last week. Now, if I could just get them to comment on what I wrote, instead of just commenting on the commentary… sigh.

Oh, right, I have a blog now. I’ll just toss another pebble in …

[Update 1: fixed the spelling of MySQL, pointed to their user community, and explained a bit more about open development at Day.]

[Update 2: clarified that Stephen's piece is separate from the IDG quote and removed an assumption of how IDG picks its sources.]

Why untangled? Because I’ve always liked this quote from Babylon 5:

“You’re a problem solver. You’re one of these people who would pick up a rope that’s gotten all tangled up and spend an entire day untangling it. Because it’s a challenge, because it defies your sense of order in the universe, and because you can.”

which is about as close a description of me as I could find, at least in the abstract. I am not quite as bad as Monk, but I love a good puzzle, and I can be exceedingly stubborn about finishing the things that I start.