Reuse Engineering for SOA
An anonymous reader writes "In most development organizations, software reuse occurs on a regular basis in at least an ad hoc manner. Code is shared across projects in an informal manner. SOA provides the mechanism for more formal reuse. So what are the issues? This article examines some of the challenges associated with the creation and usage of reusable services."
Would it kill submitters to expand acronyms? Or give a little background on the "frammazazz project" for those of us who have no idea what it is? I read some of these summaries and am even stupider than when I started. And that's saying something.
And that's why software will never be an engineering discipline.
Neither the synopsis nor the article bothered to enlighten us plebes as to what exactly SOA stands for, so I googled it for the benefit of others:
A Service-Oriented Architecture is a collection of services that communicate with each other. The services are self-contained and do not depend on the context or state of the other service.
At least, I think it's that one. Then again, maybe it's this one"
Baldurs Gate II: Shadows of Amn.
Maybe they use multi-player mode to define the problem: "Okay, so the database is the castle, right? And the balrog is a stored procedure that we all need to be able to kill - uh, run, but we only have one magic sword, uh interface to do it with...."
Okay, maybe not.
Crumb's Corollary: Never bring a knife to a bun fight.