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."

Comments

SOA is not a magic bullet

[Anonymous Coward]

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).

Re:Software reuse.

[AutopsyReport]

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.

SOA and other acronyms...

[RobinH]

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. :)

Re:SOA and other acronyms...

[trawg]

I think you make a good point, but I'd also add that often its not just the crazy new maverick that is running amok and ignoring existing systems/strategies. Doing stuff 'properly' takes longer, and if you're working in a development environment you often get deadlines that can only be described as 'unrealistic'.

Its a trade off - do you sacrifice ease of maintenance in return for just getting the job done quickly? I guess it depends how long you're staying at the company :)

Re:SOA and other acronyms...

[The Famous Brett Wat]

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.

Amen to that. And it's not always the industry newbie who's to blame. There are career programmers who've never worked any other way. And often those code cowboys are considered valuable for their ability to get code working rapidly. What's not seen, of course, is the maintenance nightmare they create in the same stroke.

Re:SOA and other acronyms...

[RobinH]

Thanks, that was an interesting read.

I feel the same way, but I understand why sometimes we take the ctrl-c ctrl-v approach and modify it. Of course, that's in my line of work where we do a lot of rapid application development of GUI's that talk to more hardened back end code, so the GUI's tend to change too much from project to project to make a completely customizable platform (and don't think we haven't tried).

What I do find is that if you keep up the lines of communication with your colleagues, together you can pinpoint specific areas where you could create a generic module that could easily be reused in current and future projects, then all agree on an interface spec, and someone goes and writes it (or adapts existing code to do the job). This seems like a decent compromise between writing everything generically vs. the hack it together approach.

I also find that the highest layer of "business logic" should never be abstracted away, to preserve some form of clarity about what the application actually does. In one case, we have a program that controls 8 different but similar stations (from the same program). I chose to NOT abstract the station into a function block (as it was called in that language), but I did abstract the various components of a station and reuse those across stations. The result was a balance between readability and code re-use. I did this because sometime over the next year or two, at 2 am, someone is going to be looking at that software with a plant manager screaming like a drill sergeant in their ear while they try to figure out what the heck it does and why one of the stations doesn't seem to be working, and if all they see is some multi-dimensional indexing nightmare, then I'll be the first one they call at 2 am.

Every situation is unique.

Same song, different verse

[cpu_fusion]

Warning, opinion ahead, intended for discussion, but some may see as flamebait. That's ok; flame me if you want.

For those who don't know the acronym, SOA means "Same Old Architecture."

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. In the end, you'll probably end up marshalling all your data around via XML over protocols originally intended for other things, like serving up web pages, maybe getting to implement synchronous semantics over asynchronous protocols (or vice versa), all the while trying to keep things nice and reusable & decoupled, etc.

And you'll run into all the same problems you would have hit before, except your CIO will be cool with that because its SOA, you know, and that's hip.

I loved hearing a first rung manager at a bank insist on doing online trading transactions with an external partner over HTTP using XML back in 2000. What a visionary.

But hey, go ahead and explain to me how SOA solves all the old problems. People who couldn't implement robust services and reusable interfaces using CORBA aren't going to magically have all their problems solved with SOA.

Re:Same song, different verse

[Bob9113]

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.

Re:Software reuse.

[turkeywrap]

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.

Same old problems

[Todd Knarr]

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?

Not gonna work

[Chemisor]

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.

Use is better than re-use.

[smileyy]

Software designed for re-use will likely never ship, or ship far later than software designed to do something.

Re:Software reuse.

[MikeFM]

No doubt the lack of reusable code is why the majority of code is buggy, bloated, and inflexible. Taking the time to build reusable components results in better code, smaller code, more flexible code, and in the end faster development time.

Novice programmers (even the experienced novices) think that quick development time is more important but all they end up doing is taking more time because they blindly recode everything instead of building upon what they've already built. Yes, it's faster the first time you code something to do it that way (if the project isn't very complex) but with each additional time your wasting time. Spend the effort up front and you'll save a lot more time in the long run.

I'm always horrified when I look at people's code and see how many of them don't even use functions let alone objects, components, and external services. I see programmers that should know better using cut and paste methods. Great.. that's quick.. until you have to change that code which means locating all instances of the code and applying changes.. which is of course made harder by the way most such developers don't comment code and often make several minor changes to various occurances of the code.

An example I attack a lot is how web-based services and applications are usually written. Rather than write a service that handles things like logins and credit card transactions you see this code just mixed in with application code. This is very standardized functionality that could easily be abstracted but instead it's rewritten over and over and ends up very buggy and insecure. You end up with everything mixed together as spaghetti code.

Try reusing that code. With a little practice and the gradual build-up of reusable parts it'll result in better code and faster development times.

It seems to me that people that actually like to program tend to reuse code whereas people who do it just as a job or to fill a need don't. Real geeks are lazy because we're overflowing with ideas. If we have to keep reinventing the wheel we don't find time to invent the cool stuff we really want to work on. That's why we invented shell scripts, pipes, pluggable components, functions, objects, services, high-level languages, development frameworks, etc. These things combine to let us do more in less time.

Read that in Dutch

[Anonymous Coward]

The title of this article does read a little strange for Dutch native speakers.

Google search on "Dutch SOA" http://www.google.com/search?q=dutch+soa shows what I mean.

Re:Software reuse.

[Tony Hoyle]

Objects are easier than functions?

Not at all.. to write objects you have to think in an OO way.. that should come easily to an experienced programmer but I've seen a lot of things that are just linear programs with the word 'class' at the top.

Web services are a bitch... I've yet to find a really compelling use for them though - I could imagine an application that uses them but have never actually been called upon to write such a beast.

Re:Software reuse.

[MikeFM]

Objects can make more complex problems easier than functions alone can do.

I've seen plenty of poorly designed objects too but that doesn't mean objects are a bad idea. I've seen horribly written software in general but I still think software is a good idea. :)

I'll assume that by web service you're refering to web-tech based components and not user apps like GMail. There are plenty of good reasons to use thse. If you're writing a complex program or set of programs that need to reuse functionality then they can be a good idea. You can reuse functionality without reinventing the wheel or sharing code (for security reasons, simplification, etc). Something as simple as handling users and permissions is a good thing to build into a service. There is no reason for every app to have it's own users and permission levels for those permissions. Why not abstract them into a service that all your apps use? Having this abstracted simplifies your logic both in the service and in the app, lets you more closely audit this important code for security flaws, and makes management of users easier.

Dangerously Costly

[ThatsSomePig]

I think the overwhelming consensus of the posts is that anyone with experience knows that this term is meant to combine a lot of generally accepted patterns that allow for long-term return on previous development and overall system flexibility. Anyone trying to tell you otherwise is inexperienced and misinformed.

Recently at PDC this topic was raised to these folks: Gregor Hohpe, David Ing, Tony Redmond, Steve Swartz and their response was exactly what you've read in these posts.

It's true that management loves this term. Have you seen the latest tech-management publications sitting on their desks? Headlines read: "Leverage SOA Now!" and such. Now, if you're someone that is held accountible for major architectural decisions and you're the one that the department manager poses these questions to, it's a fantastic opportunity to recalibrate expectations for things that you already do or have been told in the past that you cannot do because of time/cost limitations.

On the topic of code reuse, here's, humbly, how I've seen the most benefit:

• * Identify the points in your architecture that can be supported by low-level plumbing code and factor that out to shared libraries - share them however it makes sense operationally/architecturally - does not have to be exposed as Web Services.
• * Take a close look at your business and identify the core, slowly-revisioned processes and functions. Factor those out and create shared libraries - share them however.
• * Perhaps the most important thing here is to not do any of this without giving this shared functionality an explicity owner. Someone that can answer when there's a problem and evolve the design.

My 2-cents.

SOA drawbacks

[pcraven]

My opinion, the greatest drawbacks are:

1.) Versioning. Project A wants to add a feature to the service. Now we have to coordinate and test with projects B, C, D, and E. Two of which have no funding. The other is run by a moron.
2.) Reliability. I have 10 services on different machines run by different groups. All have to be up for my app to work. If they all have 99% uptime, mine is significantly less than that.
3.) Speed. Serializing data and calling across the network is slower than local. Period.
4.) Interacting with a 3rd party. If you are on a project and dependent on another group with different priorities and management, you are in for a few headaches and delays.

I could go on. I work at a large financial institution, so we have a lot of architects that prefer SOA. It has its place, but I hate to see people push it, when they don't back it up by detailing how they will mitigate the drawbacks that come with it.

UNIX haters discover UNIX

[idlake]

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.