Earlier today I read a post by Michael Feathers Called "10 Papers Every Developer Should Read (At  Least Twice). I knew some of the articles mentioned there and learnt about few interesting ones.I liked it so much,  I thought I'd compile a similar list for software architects - based on stuff I read over the years.

1. The Byzantine Generals Problem (1982) by Leslie Lamport, Robert Shostak and Marshall Pease - The problem with distributed consensus
2. Go To statements considered harmfull (1968) - by Edsger W. Dijkstra - Didn't you always want to know why ? :)
3. A Note on Distributed Computing (1994) - by Samuel C. Kendall, Jim Waldo, Ann Wollrath and Geoff Wyant - Also on Michael's list but it is one of the foundation papers on distributed computing
4. Big Ball of Mud (1999) - Brian Foote and Joseph Yoder - patterns or anti-patterns?
5. No Silver Bullet Essence and Accidents of Software Engineering (1987) - Frederick P. Brooks - On the limitations of Technology and Technological innovations.
6. The Open Closed Principle (1996) - Robert C. Martin (Uncle Bob) - The first in a series of articles on Object Oriented Principles (you remember the debate on SOLID...)
7. IEEE1471-2000 A recommended practice for architectural description of software intensive systems (2000) various- It is a standard and not a paper but it is the best foundation for describing a software architecture I know.
8. Harvest, Yield, and Scalable Tolerant Systems (1999) Armando Fox, Eric A. Brewer - That's where the CAP theorem was first defined
9. An Introduction to Software Architecture (1993) - David Garlan and Mary Shaw - one of the foundation articles of software architecture field (although based on earlier work by the two)
10. Who Needs an Architect? (2003) Martin Fowler - Do we or don't we?

I could come up with quite a few more articles not to mention books that aren't in this list. However these are definitely some of the most influential papers I read.

 

One of the SOA patterns I already described is the Service Firewall. The idea behind the service firewall is to have an intermidiator between the actual service and callers and inspect in an applicative level incoming and outgoing messages.

Anyway, while I documented the pattern as a security one, I am actually going to implement it for another purpose - a saga filter.
In our implementation of EventBroker I made the design decision to have services expose regular WCF contract. i.e. services can communicate with each other directly and not just via eventing. This design decision is there to allow both interaction with non WCF services and to allow flexibility for multiple message exchange pattern (where events are not the best choice).
Another design decision we have is that we have two types of services. Servers and Channels. Servers handle multiple sessions and are (relatively) heavy to write. Channels on the other hand are light-weight services that  are stateful and dedicated for a specific session. Naturally there are a lot of instances of channels to allow supporting multiple sessions (and there are infrastructure bits to allow allocations and propagate liveliness etc. but that's another story). Channels have several benefits like increasing the systems capabilities to cope with failure (if a channel is down only the session it supported fails). One of the benefits of Channels is simple coding model. The Channel is dedicated to a session (typically a saga) and thus it doesn't have to handle all the routing of messages to sagas etc. that Servers have to cope with. This is where the Service Firewall comes to play.
In order to keep channels' code simple "someone" has to make sure the channel doesn't get messages that are not related to the saga it is part of. Otherwise the Channel will have to know about its current active saga and filter messages by itself - which kind of misses the point.
Making sure other services will not send messages while not in saga etc. will only take us so far (you know - latencies and stuff). A service firewall will let us intercept the messages before they reach the service and only allow the messages related to an active saga to pass through (while maintaining the benefits of direct contracts)

WCF has a rich extensibility model (see figure from MSDN below). This series will show how you can use some of these extension points to implement a service firewall and achieve the goal depicted above.  I hope you'd find it interesting




 

Returning from a short blogging vacation (both personal and work related) I found my RSS reader is getting filled with posts relating to "Uncle Bob vs. Joal & Jeff or the case of the SOLID principles (OO principles by various people including Uncle Bob himself - you can also read the "OO Primer" paper (pdf/ppt) I worte on these and few related principles).

Codeclimber has the complete timeline, but in essence, Unclue bob talked about the SOLID principles in a Hanselminutes podcast; Joel Spolsky commented that "quality doesn't matter that much" on his and Jeff's StackOverflow podcast, which was followed by a few blog posts on both side like Uncle Bob's "Open letter to Joel Spolsky and Jeff Atwood" and Jeff Atwood's "The Ferengi Programmer".

I don't know Uncle Bob personally (I've seen him talk a couple of times and I read his blog/papers), so I might be off here. However (to me) Uncle bob usually comes off  as  being too religious about following practices to the letter. e.g. see the debate  between Uncle Bob and Jim Coplien on TDD where Bob says "nowadays it is irresponsible for a developer to ship a line of code he has not executed in a unit test."

Nevertheless, I am fully with Unclue Bob on this one. I especially like the following qoute from his "Getting a SOLID start"

"The SOLID principles are not rules. They are not laws. They are not perfect truths. The are statements on the order of “An apple a day keeps the doctor away.” This is a good principle, it is good advice, but it’s not a pure truth, nor is it a rule.

The principles are mental cubby-holes. They give a name to a concept so that you can talk and reason about that concept. They provide a place to hang the feelings we have about good and bad code. They attempt to categorize those feelings into concrete advice. In that sense, the principles are a kind of anodyne. Given some code or design that you feel bad about, you may be able to find a principle that explains that bad feeling and advises you about how to feel better."

You see, the point about these OO principles (and patterns and even so called "best practices") are an attempt to distill experience. Assuming these principles are worth anything (and the SOLID ones do) - You can either  ignore that knowledge and learn these lessons the hard way, i.e. through your mistakes or internalize them and apply them.

How do you apply principles - by applying critical thinking. I wrote here before that I don't like the term "best practices" since it implies you don't have to think. Sorry, being a developer means you have to think, deal with it. There's no "deus ex machina" - it is all up to you.
Any good idea can be abused, e.g. let's look at the Single Responsibility Principle. SRP helps bring cohesion into classes by  lowering the "reasons to change. It is very easy to apply it ad absurdum and get a single method classes that really only do one thing but that's not the way to go.
The thinking part means that when we implement some class, and we happen to know about SRP, we can say to ourselves, hey this looks like an SRP violation. Why am i doing this? Do I have a good reason for that etc. knowledge of principles and patterns promote making your design decisions explicit and thus having you control the design (and architecture) rather than the other way around.

One claim I read is that principles such as SOLID preach to the choir. The so called "20% of developers" who already read blogs, enrich themselves and generally know what they are talking about. Well, I don't know, but the way I see it, not all those developers are black belt gurus who feel good design by the direction of the wind or get perfect code by mumbling a few incantations. I know I am not one. That means I am always learning. Ok, so I already know about SOLID and a couple of other nifty patterns so I need to learn other stuff like good principles for functional programming or whatnot . If you are starting out on OOP though, I suggest you build yourself on a SOLID foundation and go form there