Based on Steve’s glowing review, I ordered a copy of “Release It!” And, wow! What Steve said. This is an extremely readable and informative book that every enterprise developer should read. But rather than heap more praise on Mr. Nygard, I thought I’d present here a few choice quote that resonated well with my RESTian world view.
Cynical software expects bad things to happen and is never surprised when they do.
The more tightly coupled the architecture, the greater the chance that [a] coding error can propagate. Conversely, the less coupled architectures act as shock absorbers, diminishing the effects of [an] error instead of amplifying them.
Your best bet is to keep as little in the session as possible. [Nothing, really. Ed.]
Hope is not a design method. [Sounds familiar. Ed.]
[This next one I'll quote at length. Ideally, we should have all learned this a long time ago, but sadly that's not the case. Ed.]
Integration point latency can be a serious performance problem. The problem becomes acute when the integration point uses some ï¬‚avor of remote object protocol. The â€œlocation transparencyâ€ philosophy for remote objects claims that a caller should be unaware of the difference between a local call and a remote call. This philosophy has been widely discredited for two major reasons. First, remote calls exhibit different failure modes than local calls. They are vulnerable to network failures, failure in the remote process, and version mismatch between the caller and server, to name a few. Second, location transparency leads developers to design remote object interfaces the same way they would design local objects, resulting in a chatty interface. Such designs use multiple method calls for a single interaction. Each method call incurs its own latency penalty. The cumulative effect is a very slow response time.
A system that cannot adapt to its environment is stillborn
If this group [of enterprisey, ivory tower architects] has power, they will put projects on hold until the enterprise architecture is defined. If they do not have power, they will gnaw on their own livers as project after nonconforming project rolls into production without the benefit of their architecture.
Nothing hobbles a systemâ€™s ability to adapt quite like having other systems poking into its guts.
Clearly, there is value in avoiding this [tight] coupling [between systems]. It has undesirable effects on the time to market, deployment cost, and system availability. We must design protocols so that either endpoint can change independently of the other. [Or properly use one we already have. Ed.]
Of course, not every sentence rings as true as these. Here are two that fell a little flat.
When that invisible machinery [application servers magically dealing with cookies and sessions] involves layers of kludges meant to make HTTP look like a real application protocol, it can really tip over badly.
It’s understood that what Mike really meant to say was “… make HTTP look like a more familiar application protocol.”
The sad truth is that HTTP doesnâ€™t handshake well. HTTP-based protocols, such as XML-RPC or WS-I Basic, have few options available for handshaking.
Again, to put words in Mike’s mouth, what he meant to say is that “Protocols that tunnel over HTTP, such as XML-RPC or WS-I Basic, have few options available for handshaking.”
BTW, what Mike means by handshaking in this regard is the ability for a server to protect itself by “throttling its own workload” in cooperation with a client. HTTP actually has a sizable number of mechanisms for limiting resource consumption including:
- Caching and conditional GETs
- Using HEAD and OPTIONS to query a server’s capabilities before attempting to use them
- Politely putting off processing till later (202 Accepted)
- Sending the work elsewhere (303 See Other, 305 Use Proxy, 307 Temporary Redirect)
- Simply refusing the work (503 Service Unavailable)
- Using “look-before-you-leap-requests” (Expect: 100 Continue)
Admittedly, some clients and servers are better than others at properly implementing support for these features, but that’s not to say they’re not there.
But none of this last bit is to say that “Release It!” is flawed. These are just two (and the only two) picayune things I could find. In every respect “Release It!” is just fantastic and is a must read for anyone developing enterprise apps. Not only does it have lots of fun, pithy quotes and entertaining war stories, it has real practical advice on how to create production ready software. Buy it!