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."
So you've rewritten your own versions of libgtk, libX, libxml, etc. that you understand? Cool. I'd do the same, but my time here on Earth is limited...
I agree that reuse of objects is overrated - however reuse of components is widely used - the main killer is idiots that do not comment the code / provide documentation as to how a component / module / application works so other developers often find it easier to re-write a new component rather then reverse enginer a component to work out how to use it. This is a HUGE problem with our industry ( yes I am a coder and have been so for 10+ years)
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.
Usually, I write a version of a popular library to understand it, and, having done that, realize how badly I have implemented the library in comparison to the original, and use it. It helps with both understanding and respect for your tools.
With that said, service oriented architecture strikes me as little more than the latest in a long string of TLAs so beloved by IT management and such (I.e. PHBs), but with very little in the way of real content behind it. The whole point of pretty nearly any software ever written is to provide some a service a user, so pretty clearly being "service oriented" is roughly as new as dirt.
Ignoring that, however, and taking web-service oriented software as somehow being revolutionary (even though it's really not) we're still left with a serious question about how in the world this would relate to software reuse. I'm reasonably certain the answer is that PHBs feel a need to sell their PHBs on the latest TLA, and IBM has thrown together a web page that tries to help them in that regard.
When you get down to it, however, the web page contains virtually nothing in the way of real information. It basically says that reuse is good. Whether you agree with that or not, the fact is they haven't really told you anything about how to facilitate reuse in general, or how SOA is supposed to contribute to that. They cite the usual reasons for reuse not working out well (e.g. lack of education and lack of software suitable for reuse). They go on to give the usual ideas that mentoring, careful analysis, etc., will help yield ideas for software to write that's worth reusing and more ability to reuse it.
Five years ago this article would have said "XP" instead of "SOA". Fifteen years ago, it would have been "OOP" instead. Twenty five years ago that would have been "structured programming". I wasn't around at the time to know for sure, but my guess is that if you looked carefully you could find something from the 1950's (or maybe even late '40s) talking about how the macro capability of the new assemblers wasn't resulting in as much code reuse as some people hoped, mostly due to 1) lack of education and 2) lack of macros worth reusing.
To make a long story short, "code reuse" has a long history of over-promising and under-delivering. Now, that may make it sound like I consider software reuse a lost cause, or something on that order, but that's just not true. The fact is that macros allowed some reuse of a fair number of (mostly) relatively small pieces of code, as long as there wasn't too much variation between the uses.
Structured programming helped a bit more, particularly by helping readability so you might be able to figure out what something did more easily than writing it all over again.
Likewise OOP allowed more reusability as well. Despite being the newest TLA on the block "SOA" is really little more than modular programming, with the modules in this case being relatively large. There's been a bit of work done on standardizing the interfaces between the modules, so it's a bit easier (at least in some cases) to plug them together, but in software that's pretty much what most architecture boils down to anyway -- designing interfaces.
Now, having that interface pre-designed (to at least some extent) undoubtedly makes it a bit easier to reuse a bit more software with less design specific to the problem at hand, and that's probably a good thing in general. OTOH, Brooks was right: there probably is no silver bullet, and even if there is, SOA isn't it. SOA will probably provide an incremental improvement over previous methods, at least in a few places under a few circumstances (given the amount of effort that's been put into designing the SOA interface "stuff", we'd better hope so, because it needs to help some people quite a bit to even break even).
Articles will be published crediting it with saving company X from total oblivion, triumphing over their opposition, etc. Other articles will be published blaming it
The universe is a figment of its own imagination.
Wasn't OO supposed to be the panacea for reuse a few years ago? Never happenned... (it turned out that massively complex multiple inheritence trees were worse than the rewritten objects they were trying to replace).
Then 'Extreme Programming' did the rounds... use twice the number of programmers to produce the same code... yeah rock on dude... Not sure what they were aiming at there... My last boss took one look at it and said 'over my dead body'. End of that one.
Then UML... Everyone I ever met took one look at that and laughed.. PHBs tried to push it for a while though... was almost forced to do a project in it, until we pointed out that the design phase alone would take longer than the entire project deadline (which admittedly was only 2 weeks).
Now we have a new (unexplained... SOA to me means DNS records) fad that is supposed to make programs perfect, solve world peace, etc. As ever, it's 10% good ideas, 90% hype (I bet they sell a few books on the back of it though).
Good programming is about using every technique available, within the constraints of commercial reality - and that means tight deadlines, bosses who understand nothing but results, and users who are worse.
Code reuse is a very good idea, but in practice tends to happen within small teams (who often have a library of routines that they are familiar with and work with).. Commercial libraries often suck donkey (in fact very often... since they're subject to the commercial constraints listed above) - I once had to rewrite an entire development library because it sucked so hard.. took nearly 4 days (mind you, the original developer seemed quite proud he'd done it in less than 6 months... given the complexity of what he'd produced I could believe it - they still don't teach KISS in universities I see).
OTOH you can't become too wedded to code reuse.. sometimes the spec is just different, and constantly modifying the same routine to do multiple things it wasn't designed to do creates an unmaintainable mess real quickly.. that's where refactoring and rewriting starts (seems to happen in phases... you collect and modify the libraries over a period of years, then someone says 'look at this pile of steaming crap', and it gets rewritten... years later the cycle repeats.. if your stuff is modular enough you can do it without introducing bugs).
I personally like using XML-RPC to decouple components because it is easy to work with and easy to use from any programming language. Different languages can make different problems vastly easier or harder to approach so being able to pick the best tool for each job can be a real time saver. Something that is easy in PHP might be hard in C. Something that is easy in Prolog might be hard in PHP. Something easy in SQL might be hard in Prolog. And so on. Having the code bases sepperate makes debugging and maintainence a lot easier to. You can keep each service simple and direct and just use a little glue code to tie it all together. Code you can't reuse is the oddity in my experience and is usually the bits that change often - mostly UI stuff.
I have to agree that talent is important but I think talent combined with good methodologies can create magic. When you get a few talented people that are communicating and working well together wonders really do happen.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
Bad example.
I wouldn't trust user management to an external machine over the internet. ever. If that machine is ever compromised *every* app that uses it would be compromised. This is why MS Passport never took off.
Handling users and permissions is generally done by the OS anyway.. doesn't need an external module. Application-only permissions (things like 'can edit page', 'can ride quad-bike', etc.) are not generic and change for every application, so can't be stored externally anyway.
Really you're talking about something that probably takes about an hour of some junior programmers time, is about 20 lines long and never needs to be touched. Why introduce the complexity of a web service for something like that? Heck, just borrow it from the last application that needed it...
Try doing any work in companies that develop web apps. They usually write horrible code. Most developers for such companies either have no structured software development experience or they seem to totally ignore their experience and write quick and dirty crap software. To some extent that makes sense but only for one off development of little complexity. Yes, many of these companies don't even use functions let alone objects or higher abstractions. If you think that makes life easier then you haven't tried it.
Most such companies don't do meetings and rarely have teams. It tends to be a lot of lone gonemen sitting in their own dark corners pounding out their own terrible code with no communication with anyone else.
Functions, objects, and even services are nothing new. They've all been around for decades. I hardly think they qualify as the flavor of the month buzzword technology although certain companies may be pushing their own variant (which is seldom needed). They are well know abstractions that have well known usage methodology and are taught in most decent computer science programs.
Black-ops refactoring goes on but eventually you hit a point where it takes you extra time to fix problems which makes you look bad so you just have to throw in the towel and do your work just as bad as everyone else if you want to keep your job. Most employers I had didn't even understand that new functionality, better interfaces, etc really mattered let alone things like documentation and support for disabled users.
Maybe the golden rule should be to just avoid working with small development companies? Do larger companies write better code? I've always thought small companies would make more of an effort to get things right but my evidence doesn't agree with that expectation.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
This is probably the number one reason. I have worked on several projects where re-use was a goal, and the software produced was difficult to understand, error prone, badly documented, and inflexible. Re-use is possible though, the best examples are the Java and .Net libraries which are very good.
Another problem is that the technology changes rapidly enough that a re-usable library can become obsolete rather quickly. I don't know how many user interface libraries I have written (starting with an X-Window/Motif library) that are pretty much worthless in may current job.SOA is not "runtime reuse".
You know nothing of SOA. You post anon. You don't deserve a rating of 5 - I think "troll" would be more apropos.
This entire thread is full of FUD - but what's really scary to me is that this is /. where technologists theoretically hang out.
Yet, perhaps I should expect this kind of closed-mindedness, given how (mac|mike|php|mysql|ajax|...)-fans tend to just let 'er rip when it comes to the chance to blurt out an uninformed opinion.
Briefly, because I'm afraid I'm passing time in the same fashion as I would at a very, very bad movie - SOA is not going to impact you gamers. Nor you OSX types. Nor you windoze-lovin' 802.11G Cardbus types (you know, the ones Linux won't be supporting for a year or two?).
No, SOA is changing the business landscape in unbelievable ways. It's evolutionary, not revolutionary. The list of companies is impressive, and growing. And there is no looking back.
Points:
Many companies are approaching this both top-down (CBM & ESB) but I suspect many more are doing it bottom-up (Web Services using SOAP over HTTP or HTTPS or JMS). My last two clients are doing it bottom-up, and they anticipate hundreds of Web Services in the next year or two. Reuse of "Web Services" can be nearly impossible, just as it has been for every technology/approach in the past. Reuse under SOA is virtually guaranteed - because the tools are graphically assembling the underlying services.
I don't know why I'm moved to post on this thread, usually I just ignore the rhetoric and the vitriol, and read the dozen or so interesting posts on any /. discussion thread that exceeds 100 replies...perhaps it was because I only saw one or two semi-literate or informed opinions tonight.
Jesus wept! Flame on if you like.
Redundancy is good; triple redundancy is twice as good! - Me.
Over the Internet? You can ue web technology without running your code over unsecured portions of the Internet. Secure services should run deep inside your network on your most secure machines. There is some risk that reusing such code could create a single point of failure but that isn't much since someone that's penetrated your network to the most secure depth is likely to already have the run of the rest of the network.
Handling application users and permissions should not be done by the OS. There are many times when apps need to share users across multiple systems including systems of different types. Also there are many times when you don't want all application users to have user accounts of the systems running the apps. Would Slashdot want to give Unix accounts to every Slashdot user on the Slashdot servers? Hardly a good idea. Rules are rules are they are just as easy to abstract across applications as they are to apply to apps in general. To the apps it shouldn't matter.
You're approach is really why web apps are so buggy and insecure. It's not about how long it takes to write the code - it's about writing good code that is maintainable. I've yet to see code that 'never needs to be touched' in the real world either. Eventually everything needs new features or bug fixes. Perfect code is incredibly rare especially when written by inexperienced junior programmers in twenty minutes.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.