A Bazaar and RESTful Week

The past two weeks I've had a great opportunity to take a few breaths from my role as a Storage Management Software Architect. My background is more in general software and, as such, my breather consisted of FINALLY reading "The Cathedral and the Bazaar" and taking the time to read the fine paper from Roy Thomas Fielding on "Architectural Styles and the Design of Network-based Software Architectures". The former is the definitive book on Open Source Software (OSS) and the latter is the definitive guide to the REST architecture style, the style that guides the development of the World Wide Web (WWW).

First, the book. When The Schwartz first announced giving away our software for free and then open sourcing much of it, I definitely raised an eyebrow. Still, after chatting with folks in marketing and thinking about it, the move made a lot of sense. "The Cathedral and the Bazaar" goes to great length to discuss the economics of OSS in terms of amortization of resources as well as the economics of OSS for those that use it as well as help develop it. It is a great book from both a historical perspective, as well as a current perspective on how Sun's strategy can benfit both consumers and Sun Microsystems.

Although the current version of the book has undergone updates, many of the examples are from the days of Netscape open sourcing the browser and Linux as it started to penetrate the Fortune 500. Still, a lot can be learned from the book, though its important to keep it in perspective as one viewpoint.

If you haven't read the book, it is a collection of several essays addressing various aspects of OSS. In the namesake essay, "The Cathedral and the Bazaar", the author presents a set of lessons and examples to take away. My favorite was #2, "Good programmers know what to write. Great ones know what to rewrite (and reuse)". There is DEFINITELY not as much reuse as there could be, though I've seen it increase substantially. In the project I last architected, I presented a set of rules to the team members very early on and kept them on our community blog. The first rule was "We are lazy", implying we first looked for code to reuse and coopt from other projects. Another rule was that "we are application developers, not infrastructure developers". This is important, software engineers LOVE to write infrastructure. Its the proverbial insect light...we get all googly eyed over database access tiers and web servers and before you know it...ZAP...the project is toast when you think you've invented a new OR mapping paradigm.

Overall, lots of lessons to ponder in the book. There are a few too many "I"s for my liking, but it is an I/blogging/soap box sort of world these days anyway ;-) There are definitely a few gaps in the essays, hopefully I can squirrel away enough time to finish a paper I started while I was reading the book...stay tuned :-)

Onto the REST. REST is an architecture style. What is an architecture style???? Its basically a group of architectural properties that define a distinctive, identifiable style of architecture. Mr. Fielding does the best job I've ever seen into delving into architeture styles and exploring a nice subset of properties with their advantages and disadvantages. This lays a foundation for the presentation of the Representational State Transfer (REST) Architecture Style. The first half of the paper is basically a lesson in architecture, the second half of the paper discusses REST with examples from the Web.

When people discuss REST, they use the WWW as the definitive example. And, based on the history that Fielding gives, there is good reason...REST was derived from early (relatively undocumented) Web architectures. Now, REST is used to help guide the evolution of the Web and extensions to HTTP. Perhaps the best part of the paper, to me, was after the foundation was layed and REST was presented, the author went through a variety of "Architectural Lessons" learned. Within this section, the author describes the advantages of a Network-based API as opposed to API libraries, why HTTP is not RPC, and a missing piece of HTTP (matching responses to requests) due to the fact that HTTP is synchronous as opposed to an asynchronous model that you would expect after reading about the REST architecture style.

The paper is a great read for a variety of audiences (new architects trying to understand the implications of "Architecture Style" and how to apply various styles, people trying to wrap their head around how the Web works, and the author even weaves in references to why frames (remember frames?) are dangerous and misplaced based on the REST architecture style.

Both the book ("The Cathedral and the Bazaar") and the paper ("Architectural Styles and the Design of Network-based Software Architectures) are must reads.

Hmmm, could be some crazy weeks coming up :-) Armed with some new perspectives I should be able to go into them satisfied that I have knocked a couple of things off my "ToDo" list that should have been taken care of years ago...where does all the time go?

Comments:

Post a Comment:
Comments are closed for this entry.
About

pmonday

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today