Those who have been following my blog for the last few years know that I have stopped blogging about Service Oriented Architectures, SOAP, REST, etc. I would like to think that I have moved on, leaving the space for those who actually actively practice building systems in the enterprise. I personally prefer the cloud and semantics these days.
That doesn't mean that I don't continue to monitor what's going on. Jim's recent blog entry reminded of the good old days :-)
Jim was taught by Prof. Pete Lee. I never had the pleasure of taking one of Pete's classes since I moved to Newcastle after my Bachelors in order to do my MSc. and PhD. I did have the honor of having Prof. Paul Watson as my PhD advisor. I learnt a ton next to him but perhaps the most important thing was how to discuss and write about technology-related ideas in public. When one disagrees, one has to offer alternatives, to explain in a calm way his/her point of view, to articulate facts, to present examples, to maintain high levels of professionalism. It's all obvious really but apparently not everyone seems to get it.
I never put dates on patterns. Service-Orientation is not something new. Our understanding of how to apply and use technologies has evolved over a number of years. In most of my discussions of MEST I highlight the fact that it's nothing new, it's nothing that the distributed computing community was not aware over the years/decades of practice. It was just putting a name to a combination of patterns... that of message-orientation in the context of service-oriented architectures. At the end, it's all about messaging. One could say that the Web has brought a different architectural style into the picture, that of resource-orientation. Again, nothing that the CORBA, DCOM, etc. communities were not aware of. It's just that different times and different solutions highlight different aspects of our understanding; new needs and new technologies force us to rethink and re-articulate the same principles, use new terms, write new articles, give new presentations.
To me, what Jim says is obvious... He articulates a pattern, he proposes common practices for building enterprise systems. He has the experience as he applies these ideas for different customers; he's well respected and always a joy to interact with him. His communication style is unique... perhaps one of the reasons he's so popular at conferences and keynotes; probably because what he says makes sense and resonates with many people.
Do I always agree with Jim? Absolutely not... Just ask Mark Little and others from Newcastle who were always surprised how the two of us got along... "How is it possible for you two to argue all the time and still support the same ideas?" people kept asking us. Well, it was all due to the respect we showed to each other's views, to each other's approach. We critically analyzed each other's ideas, to the point where most problems/weaknesses were filtered out, but not all. Our blogging allowed us to get feedback from the community, engage in discussions based on respect for everyone's views. It's just technology, it's never personal. (oh... I miss working with Jim :-)
Why this rant? Well, I read Jim's post on the "Anemic Service Model" and then Jean-Jacques Dubray's response to it, which I found it to be EXTREMELY rude! To me, it demonstrates arrogance and lack of communication skills. I subscribe to what Jim says. He merely puts into context what has been common knowledge amongst practitioners for years (or even decades as Mark Little comments). Yes, the images are old; I know they are old because I drew them back in 2003 or 2004 for our papers and presentations at the time. Nevertheless, I believe that they still accurately capture some design principles, even if the technologies change. Would something like the following make better sense? It's wayyyyy too abstract. Would this represent the "modern SOA" to which Jean-Jacques alludes? I can put whatever I want behind a service boundary while making sure that no internal details leak. Standard SOA pattern practice. Based on this very simple diagram, I can build/compose any arbitrary architecture (whether service-, object-, or resource-oriented).
But we need to go beyond this, beyond the figures and the technologies. What Jim says is that when putting systems together, these services should really implement something that makes sense to the larger whole. Enterprise architects don't have to worry about individual services only, like those building cloud services. They have to design their services as the building blocks of a larger whole. Those building blocks must do something useful so that they are good citizens to the whole system (cohesion) but, at the same time, they should not introduce any cross-building-block dependencies that would make them difficult to replace (loose coupling). To my mind, if one is an enterprise architect and does not follow this simple advice, they are doing disservice to their employer.
Architectural patterns emerge through practice and not designed by committee. I've seen too many attempts to "standardize" architectural patterns... it's just not possible. One could create standards for protocols but architectural patterns? It's crazy. It's like saying that we can standardize the way artists express themselves. This also applies to putting dates to patterns. How can the principles that governed SOA be much different today from 3-4 years ago? I can understand if a new pattern emerged, if a new way of doing things became popular because of its additional value. But to suggest that there is "new" and "old" SOA? :-)
Folks should really chill and not convert technical discussions to personal attacks. I find language like...
"I would really recommend that you spend more time understanding SOA and less time trying to create specs that are absolutely counter to SOA principles.", and
"...is one of the dumbest recommendation you can make. You are no George Lucas, there is only one thing anemic about your post, it is your understanding of SOA."
extremely unprofessional.
Update: Complete lack of communication skills! Read the follow on post by Jacques and his comment-reply to Jim.