Noah Campbell

I haven’t been able to jump on board the REST movement as the one true way. I love exploring the concepts and ideas, but I don’t feel that REST represents the culmination of an ideal architecture that requires ignoring SOA or traditional Enterprise Architecture. REST is currently the incumbent (although it has been around for quite some time) so it doesn’t have the battle scars that SOA and EA have chalked up.

On the SOA mailing list on Yahoo!, I found this quote to be interesting:

“Master data management is hard but critical to the success of SOA,”
he said. “Most users tend to clean up data in Excel. If you leave it
to them, you will get their own versions of the truth.”

Obviously I’m taking it out of context, but to me I interpret Master data management to deal with the domain that REST is revealing. REST requires a fundamental shift in how application architects think about their data especially when it comes to state transfer. SOA, if it’s going to be able to scale will need to look at what makes REST scalable from the beginning. But to be fair, SOA and REST don’t represent perfect comparison. REST to WS-* is perhaps the most significant battle ground on the mailing lists. The folks at Amazon, eBay and Salesforce have made WS-* scale and have the bumps to show for it.

Where does EA fit into all of this? Well, EA is the arc between all the decisions that must be made about technology, architecture and practice.

“If EA can ensure that the artifacts it creates are consumable at the
project level, then absolutely, SOA will be folded into EA. If EA is
not creating artifacts that are consumable at the project level, then
we have a problem.”

So, EA’s are on the hook for bridging the right decision to the right business situation, like they’ve always been.

PatHelland’s WebLog : Memories, Guesses, and Apologies

Replication can force apologies. This is the same crap we have to deal with when the physical realities are out of sync with the computer’s knowledge, [Please note: I am NOT saying that all replication errors are identical to the business realities. I AM saying that when you replicate business operations (rather than the back-end state of your internal database), the shape of being out-of-sync does, indeed, mimic the business realities.]

I believe this is perhaps one of the most fundamental ideas that every architect should consider in their design. REST is perhaps the closest technique that we have today to achieve what is being discussed since cache/replicas are addressed with the cache control header, however there is still a lot to be desired since REST only focuses on the notion of a single logical replica, acutally getting a significant number of replica’s to sync is an exercise left to the implementer.