Geeks With Blogs



Add to Technorati Favorites

An Archived Managed World This blog has moved to

Don Box made an insightful post clarifying some of his statements that have been warped out of context as of late.

I totally agree with Don on this one. SOA does not mean the end of Objects. While Services are wonderful and can be pretty powerful in a large, distributed application, they can be overkill for a smaller project. If you're going to plant some small flowers in a flowerbed, you would not (at least if you are somewhat sane) plant those flowers using a large Bobcat.

The problem I see with SOA is not a problem with the architecture itself, but with the application of that architecture by “software engineers”. It's eerily similar to the problems I see with Software Design Processes. In software development, there is no such thing as a “silver bullet”, whether it be with testing, development, deployment, etc. If you look around, you see these phenomena a couple of times every few years, basically everytime a new acronym comes across our table, OOP, XML, XP, and now SOA. When you're holding a hammer, everything begins looking like a nail.

Why does this occur? My belief is that this occurs when developers start to emphasize technology over the problem domain itself. I guess one could say it is human nature. Better yet, one could say it is man nature. We Men have a tendency to start trying to solve a problem from the start (even if there is not a problem to solve). Women, on the other hand, tend to discuss the problem first. Listen! Listen! Listen! I'm sure when the wheel was invented, men started putting wheels on everything.


Consumer: “Excuse me, dear sir, but what is that nifty contraption that you have there?“

Inventor: “It's the latest, greatest, bestest, friendliest, rolly-iest device invented to date“

Consumer: “Yeah, but what is it?“

Inventor: “Uhhhh, well actually, it's a full size picture of a man of the future (called “The Rory“) on “wheel-blades““

Consumer: “whatever...“

Or something like that. I'm not sure if “The Rory“ was really known that far back, but I like to thank so. After all, if he's as popular as he is today, why can't he be that popular several centuries ago? If you think about, The Rory has such amazing Star Power that he basically transcends the Space-Time Continuum. My own theory is that The Rory is the real-life embodiment of “Q“. But I realize some of you may not agree (those that don't agree with me can go to H-E-Double Hockey Sticks (I'm just kidding (not really kidding but kind of joking (and by joking I mean that I am totally serious)))).


Anyways, how do we fight this “nature“ of ours when applied to software engineering? I think that the most important point to make is that when you are first analyzing any problem domain, DON'T THINK ABOUT IMPLEMENTATION TECHNOLOGY!!! Discover what the problem domain is all about first. Only after you understand the problem domain fully can you start asking what technology is best suited for implementation. After all, it may be that J2EE is the best environment, or .NET may be the best environment, or perhaps unmanaged-C++ may be better.

In closing, when you are engineering application, don't think like a developer. Put on your “engineering hat“ (aka, “Women Hat“ for us Men ;~)) and attempt to fully understand the issues at hand. Good Luck out there and happy engineering :~).


Posted on Saturday, January 31, 2004 4:42 PM | Back to top

Comments on this post: Future of Objects and Services

# re: Future of Objects and Services
Requesting Gravatar...
I've said it before, I'll say it again - SOA is about what the problem IS. Layered Architecture (LA) is about solution is.

Every service should correspond to a concrete set of requirements. Entity services include the persistence service. Persistence being about the ability to save and retrieve information over long periods of time and system restarts. The infamous DAL is used more as a pipeline for making SQL calls. Obviously the persistence service would contain SQL in cases where the store is a database. But that's just details.
Left by Udi Dahan - The Software Simplis on Feb 01, 2004 12:59 PM

# re: Future of Objects and Services
Requesting Gravatar...
"SOA is about what the problem IS"

I don't believe that SOA is always about what the problem is. For a truly distributed application, yes, SOA can be about what the problem is. For example, look at a simple Windows application like MSPaint. I think an architect would be pounding a "square peg into a round hole" when using services. Of course MSPaint isn't an enterprise-level application, but what about Adobe Photoshop?

There is no doubt that services can be a beatiful thing, when applied properly to a suitable problem. One has to ask what the power of services are first though. In my opinion, the power of services come from not only the reusability of the code base, but also the maintenance and deployment of the code base. However, this is only really true when dealing with a data-centric application. Granted, most applications today seem to data-centric or are becoming data-centric.
Left by Jason Olson on Feb 01, 2004 6:35 PM

# re: Future of Objects and Services
Requesting Gravatar...
You can still mash your thumb with a high-quality hammer. It doesn't mean that it's not a better hammer. =)
Left by Udi Dahan - The Software Simplis on Feb 02, 2004 3:40 PM

# re: Future of Objects and Services
Requesting Gravatar...
Do you thinkthat you coul help me? im doing a project and i need to know what objects the children of the future will have that modern children do not have. Please help !!!!!!!!!!!!!!!!!!!!!
Left by Miles on Nov 22, 2004 7:40 AM

Your comment:
 (will show your gravatar)

Copyright © Jason Olson | Powered by: