Slashdot Mirror
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.
Too many managers are trying to jump on the SOA bandwagon. SOA is basically "runtime" reuse. But there are plenty of valid ways to do code reuse before runtime, hence functional decomposition, OO design, or componentized architectures. Don't fall for the marketing hype about SOA being able to fix every problem that ails you.
If you have a large company with a bunch of legacy or disjoint applications, SOA could be a great way to solve some of your business needs. If not, then keep an open mind and look for the right solution (and don't trust vendors).
I'm thinking you either work for yourself, or work for a company that doesn't monitor your programming habits. Otherwise, software reuse can be time-saving and is widely used. Even though knowledge of previously written code isn't always passed on to the next developer in such a way that they completely understand it, that usually does not warrant a complete rewrite. Code that is written to be reused, however ambiguous, usually can fufill its purpose.
For he today that sheds his blood with me shall be my brother.
Service Oriented Architecture (SOA), etc.
:)
In my limited experience, there are a lot of "software methodologies" out there, all claiming to make software better (i.e. more scalable, efficient, better re-use, etc.). Of course it all comes down to modular programming, good documentation, and agreement among the developers in an organization on a plan for how everyone is going to do things so that everyone is on the same page.
Also in my experience, more than half the developers at any reasonably sized organization are not really capable of dealing with abstractions like SOA, OOP, or whatever. No matter how well laid your intentions are, and how many rules you create, there will always be some new hack straight out of some college course who dives in and gets the job done, but manages to totally screw up the whole system you and the senior programmers had in place. Then it either goes unnoticed until it becomes a problem (when the next change has to be made), or you have to spend half a day undoing the damage they did, and doing it correctly. Either way, the new guy looks like a genius for getting it done in half the time it would have taken one of the older guys, and you look like an inflexible nimrod that's just getting in the way of productivity.
You want an acronym that works? Here it is: PR (peer review). Find some other smart guys in your company, and team up to review each others' work, share ideas, and build a common set of best practices. Don't let people outside that group touch your code.
"I have never let my schooling interfere with my education." - Mark Twain
Organizational impediments -- e.g., developing, deploying, and supporting systematically reusable software assets requires a deep understanding of application developer needs and business requirements. As the number of developers and projects employing reusable assets increases, it becomes hard to structure an organization to provide effective feedback loops between these constituencies.
Economic impediments -- e.g., supporting corporate-wide reusable assets requires an economic investment, particularly if reuse groups operate as cost-centers. Many organizations find it hard to institute appropriate taxation or charge-back schemes to fund their reuse groups.
Administrative impediments -- e.g., it's hard to catalog, archive, and retrieve reusable assests across multiple business units within large organizations. Although it's common to scavenge small classes or functions opportunistically from existing programs, developers often find it hard to locate suitable reusable assets outside of their immediate workgroups.
Political impediments -- e.g., groups that develop reusable middleware platforms are often viewed with suspicion by application developers, who resent the fact that they may no longer be empowered to make key architectural decisions. Likewise, internecine rivalries among business units may stifle reuse of assests developed by other internal product groups, which are perceived as a threat to job security or corporate influence.
Psychological impediments -- e.g., application developers may also perceive ``top down'' reuse efforts as an indication that management lacks confidence in their technical abilities. In addition, the ``not invented here'' syndrome is ubiquitous in many organizations, particularly among highly talented programmers.
This is exactly why software reuse doesn't happen often enough. I took a class in Software Reuse and Design and I paid attention long enough to gain the following two insights:
1. Software reuse is hard
2. It only happens if people want it to happen
You can build a completely usable system which enables effective software reuse and thus reduces development time, but it won't do a thing for productivity if no one wants to use it.
Companies can foster an environment of reuse, which helps with Number 2. Number 1? We didn't find a way around that one.
The big one is simple: "There's no such thing as reusable code, only code that has been reused.". It's very difficult to design code to be reused and get it right until after you've actually tried to reuse that code somewhere else and found all the problems. All code makes assumptions about how it's going to be used, and you usually don't realize which ones are true showstoppers until you go to use that code in a different way and get smacked in the face by them.
The rest of the problems with SOA are the same ones that've been around ever since someone throught up remote procedure calls. If you aren't familiar with RPC and XDR, what makes you think you won't make the same mistakes and face the same problems this time around?
1. Creating good interfaces is hard. Really hard. Most programmers create lousy interfaces that nobody but them wants to use. I know; I've written quite a few of them. Good APIs take thought, creativity, and a lot of effort, none of which are allowed in a typical business environment.
2. Reusing code will not necessarily save work. See point one for the first reason. The second reason is that it is often faster to reimplement the functionality and then refactor. This generates more code than reusing someone else's library, but may save development time. Saved development time is a good thing in the type of business that is always in crunch time.
It's a clever way for the folks who brought us distributed objects to resell "new" solutions and consulting. What you have is basically distributed objects, with the design patterns that anyone who had half a brain would have already implemented if they were using distributed objects.
Distributed objects were discarded years ago as unworkable. The first EJB designs used distributed objects, where every method call goes over the wire. Since then, J2EE has moved towards coarse grained method calls, but many practicioners still see it as a distributed object. SOA is more document oriented, or data transfer object oriented. The entire mindset shifts towards serialized structs. This results in server and client logic being more cleanly encapsulated.
Much as the core technical processes of OO can be simulated in most any language, the techniques used in SOA can be applied to most any client server architecture. However, most OO client server architectures (CORBA, RMI, J2EE, XML-RPC) either have distributed objects as their guiding principle or have no guiding principle.
In short, stating that distributed objects and SOA are synonymous betrays a lack of understanding of the core objective of SOA, which is minimal coupling between server and client. Distributed objects are inherently more coupled than is the goal of SOA.
Obviously you are right that poor programmers (who are the majority) will still write highly coupled, fragile software. SOA isn't a magic solution to failing to hire skilled practitioners. But to the skilled practitioner, the core principle of decoupling the client and server is a useful guide.
Stop-Prism.org: Opt Out of Surveillance
Service-oriented architectures is basically the UNIX philosophy: lots of little tools, often implemented as little servers. Yes, it helps with reuse, it helps with limiting the effects of errors, and a whole set of other problems. What else is new.
It's funny that this is now becoming popular among the UNIX haters (you know, like many object oriented developers, Windows developers, mainframe programmers, and all those guys). But, of course, they couldn't simply just use the approach, they needed a new acronym, massive amounts of new syntax and protocols, a constant stream of hot air, and preferably gigabytes of memory to implement it all.