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

Software reuse.

[milhous3030]

Software reuse is overrated, every one claims to be able to resue software with components and objects, but at the end of the day, we all write our own version that we understand.

Re:Software reuse.

[Anonymous Coward]

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

Re:Software reuse.

[Fyre2012]

Personally, i find the 'reuse' comes from the main algorithms themselves, not necessarily how someone labels their classes/functions etc.
exactly right tho, in that we put things together in a way we understand, but thats not to say it's without implementing an idea for moving around data (in whatever way is needed) which has been written elsewhere.
"Effective, systematic software reuse continues to be an elusive goal for many organizations."
i'd wager that licensing issues have an impact in this arena, not just lack of a 'remix-this-code' tool set / methodology.

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.

Re:Software reuse.

[nzNick]

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)

Re:Software reuse.

[marcosdumay]

Software reuse is not overrated. It increase the potential of the programmers and reduce the number of bugs on the applications.

But as you said, because of a lot of factors, software reuse is just not applied.

Re:Software reuse.

[cpn2000]

I agree that code re-use within organizations is over-rated, but code re-use in the broader scheme of things is absolutely there, and growing. Over the years of doing server-side Java programming, I have come to increasingly rely on the various apache (and other such Open Source) projects to provide everything from XML parsers, to IDEs.

On the other hand code re-use within organizations is rare, but I think that is mostly a process issue, not a technology one. In my experience product development companies have much better processes to foster such re-use, while non-software companies, where the IT division is more a necessary evil, rather than an asset, do not.

Re:Software reuse.

[Anonymous Coward]

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.

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.

Re:Software reuse.

[slipnslidemaster]

FTA: "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, where the reuse occurs when services are accessed by service clients to perform a given function. The reuser (service client) does not really even know what code they are reusing, and don't really care. They just know that the service is providing the function that they require."

Wow, it's 1990 all over again except I'm reading Dr. Dobbs and Programmers Journal about OOP. Everything old is new again.

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.

Re:Software reuse.

[MikeFM]

Except services is another step of abstraction beyond objects. The major difference being that services can more easily be on other machines, can have different permissions, and can be written in other languages. In general services are much easier to program to than just using pure objects in much the way that objects are much easier than pure functions and functions are easier than goto's. To keep getting more done we have to create more and more abstractions. Each slows the software slightly but lessens development time required and gives additional flexibility.

Re:Software reuse.

[Tony Hoyle]

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

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.

[Anonymous Coward]

Funny, I often have the opposite experience.

When I re-implement something, I usually understand all the corner cases. I usually do it test-first style, so I have 100% test coverage (good as a form of documentation as well). I know what happens if a NULL or blank string is passed. What happens when the disk fills up or memory is exhausted. What happens if a buffer overflow is attempted, or characters outside of the expected set are passed.

And usually my implementation is simpler, because I removed some stuff I didn't need, but the library writer had to add for symmetry or completeness (getXXX and setYYY even if only setYYY is needed). Or I removed some print statements or debugging code that would best be implemented elsewhere.

That doesn't mean I *always* rewrite libraries. Sometimes I use them directly, or write a wrapper that fixes problems or makes the interface more rational. Sometimes the external libraries are really great.

So I wouldn't always assume that third-party library writers have necessarily done a very good job.

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.

Re:Software reuse.

[Tony Hoyle]

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

Re:Software reuse.

[FriedSpam]

I've always tried to draw an analogy to the physical world. In car manufacturing, what component(s) gets 'reused' more: a complete engine, or an individual bolt. An individual bolt has many more applications than a complete engine. Therefore, small useful software components will likely be reused more than large complete components.

Re:Software reuse.

[Javagator]

Software reuse is hard

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.

Re:Software reuse.

[Anonymous Coward]

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

Actually, pair programming is a simple enough idea - two different minds working together on the same problem. From experience, it works pretty well for complex tasks, since the process of keeping the two people in sync tends to catch bad ideas before they goes too far, and it also ensures that at least two people have understanding of both the code and the business logic behind it. Think of it in terms of a code-review, but with two people reviewing each others work as they go, instead of after waiting for it to be finished.

For simple tasks though, it's almost certainly a waste of resources. If the task is relatively trivial such that one person is unlikely to make mistakes, then doubling the number of people involved isn't going to help. On the other hand, it can be good for training, giving the new guy some simple work to do, with an experienced hand working with them.

Re:Software reuse.

[MikeFM]

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.

Re:Software reuse.

[Profound]

You're right in the idea that the real reuse happens with the bolts of the software world, which are small (in interface complexity) useful things like containers (hash tables, lists) and algorithms like sorting.

However, one of the goals of programming is to turn ever more complex things into new bolts and build bigger and better things. Eg this doesn't make much sense for a car, but is perfectly fine for code:

Car() {
        engines["economy"] = new EconomyEngine();
        engines["speed"] = new TurboEngine();
}

void drive() {
        engines[mode]->run();
}

Re:Software reuse.

[jadavis]

Re-use is possible though, the best examples are the Java and .Net libraries which are very good.

You can view a standard library as an example of code reuse, but I think there is a fine line between "code reuse" and a language with a rich vocabulary.

Java is a minimalist language, so many of the simple functions are implemented as libraries. That's not "good" or "bad", it's just a design decision. However, perl has a built-in regex processor, while Java has a library. Is java reusing code better than perl in that example? No: they both just provide some basic services to the programmer in different ways.

Re:Software reuse.

[Erik Hollensbe]

I agree that there is a line, but I think you are making too many strong assertions here. Using a lot of personal examples doesn't always count for much.

For starters, 2 weeks to design and code anything of enough girth that requires design time is an insane deadline to meet, or code way to small to bother with UML. UML is for larger systems, and works nicely if you have a system like dia2code or Visio's setup that allow you to generate the classes from the diagrams.

I haven't investigated extreme programming much, frankly, the name turns me off. However, the loop of constant checking with the user, compared to a waterfall design where the code is expected to magically pop out working, sane and meets the user's expectations isn't exactly sound, either. I don't think many design methodologies make much sense, as they don't really account for variables much. However, extreme programming is a step in the right direction towards a better system, even if it's not it.

I once had to rewrite an entire development library because it sucked so hard.. took nearly 4 days...

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

With those quotes extracted, do you see the problem you're presenting for yourself? Modifying the same routine constantly indicates a design flaw, not an invitation to throw more cruft at it. If you nip them early, they tend to not turn into giant messes in the long run.

Re:Software reuse.

[eelcoh]

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

I'd think OO did result in more reuse, but OO always stayed an IT concept. The difference here is that services are more a business concept than an IT concept. I work at a large company that started thinking about SOA a couple of years ago. At first services were difficult to implement, largely due to costs and image. But now the number of services has come to a critical mass, and it becomes obvious that they provide the best way to bring back-end products to sales channels. I never heard any business person talk about object or classes, but i did hear them talk about services.

With SOA, you will not just reuse code, you will reuse back-ends. There's one drawback, and that is that testing becomes more complex, simply because there are back-ends.

Acronym Expansion

[Anonymous Coward]

SOA - Service-Oriented Architecture

Re:Acronym Expansion

[VoidWraith]

Thank you. I hate it when summaries use acronyms without expanding them. Especially, of course, when I don't know what they stand for!

Re:Acronym Expansion

[Anonymous Coward]

And in practice SOA means loosely coupled functions, objects, and web services (typically REST, as you'll see).
By loosely coupled I mean in the interface design so not exposing any java/.net/php/whatever specific objects or pecularities, and making these program libraries more stand-alone... less dependent on other services.
So it's an architectural style, not a standard.
SOAs are discovered (plugins) or used (web services) at run-time.

Ok, I've worked all day and I'm grumpy, but ...

[John Jorsett]

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.

Re:Ok, I've worked all day and I'm grumpy, but ...

[Fyre2012]

would it kill posters to read articles before posting?

from the FIRST LINE in TFA:
Explore the inhibitors to software reuse as they apply to Service-Oriented Architecture (SOA) and learn how reuse engineering can make a positive impact in realizing the value of SOA.

Re:Ok, I've worked all day and I'm grumpy, but ...

[XFilesFMDS1013]

would it kill posters to read articles before posting?

You MUST be new here.

Re:Ok, I've worked all day and I'm grumpy, but ...

[Fyre2012]

in comparing our UID's, you MUST be 67,817 users newer than I

It was a good joke tho =)

Re:Ok, I've worked all day and I'm grumpy, but ...

[Anonymous Coward]

Hmm...especially given the fact that the acronym in question has a completely separate meaning that existed long before the intended meaning...

Am I the only one who saw SOA and thought DNS???
(hmm...I could expand that, but I'm just going to assume everyone knows what DNS is).

Re:Ok, I've worked all day and I'm grumpy, but ...

[John Jorsett]

from the FIRST LINE in TFA:

The point of my post was, I'd like to know BEFORE I RTFA roughly what it's about. I don't have much interest in reading about the Servants of Athena, or Slimeballs of Argentina, or whatever, and I wouldn't have to bother trying to fight through the /. effect to find out that it's about a topic I don't care about.

Re:Ok, I've worked all day and I'm grumpy, but ...

[Da Fokka]

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.

Seksueel Overdraagbare Aandoening.

It's dutch.

It means 'Sexually Transmitted Disease'.

You've been warned.

Re:Ok, I've worked all day and I'm grumpy, but ...

[lifespan]

Remember that episode of the Simpsons where Homer becomes a member of the Buffalo lodge where members lord it over each other based upon the number they were assigned on joining?

Re:Ok, I've worked all day and I'm grumpy, but ...

[Fyre2012]

no, i don't watch tv (I know, Simpsons !=TV but still)
but...
M$ sucks but the mods don't know that cuz they're morons or Bill G8s pays them for FUD. Well i have an Altair 8800 running Gentoo, root that pwnz0rs!
so where's my +5?

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:SOA is not a magic bullet

[Bill Privatus]

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:

1. SOA is not "an API". It's an enterprise architecture. SOAP is an "API". JMS is an "API". Same for HTTP.
2. SOA does not stand alone, any more than SOAP does. SOA needs analysis (such as "CBM", or Component Business Modeling), and a common fabric (such as "ESB", or Enterprise Services Bus). Both are strongly recommended (read: required --- only fools will sneer at these).
3. The market is around US$10B this year, and according to Gartner (IIRC), it'll be US$95B in the next decade or so. That's Billion with a B.

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.

Electronics reuse.

[Anonymous Coward]

And that's why software will never be an engineering discipline.

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

[Jeff DeMaagd]

Peer review seems like a pretty good idea. One of the ideas of "XP" - eXtreme Programming, is that you get two people that you get pairs of programmer, they cooperate on the same code at the same program. I think that's highly unrealistic though, though proponents of XP claim that it saves in problems in the long run by reducing bugs that crop up later.

Re:SOA and other acronyms...

[MikeFM]

My bad luck is that every programming job I get is where the sloppy developers have risen to the top for seeming to be faster. Try to use functions, objects, services, etc and you get your ass stuck at the bottom of the ladder or worse you get fired. Management doesn't care if something is faster in the long run because all they can see is that it is slower in the initial development. Hell, even code comments and design documentation is a luxury I rarely see. It can really drive a programmer nuts to not be allowed to use any sort of abstractions or other 'time wasting' methods. Working with old code that's been designed this way is nothing short of a nightmare because you're under a time limit and not getting the changes done quickly makes you, not the original programmer, look bad.

Okay.. I'm bitter..

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

[Tony Hoyle]

Try to use functions, objects, services, etc and you get your ass stuck at the bottom of the ladder

I'd love to be somewhere where they don't use functions... ..and they may not look like they're using objects, but I bet they are (passing context handles around functions is still objects, just a bit more opaque).

First thing to do in a new project: call a meeting. Management like that. Go over the design, and discuss the best way to implement it. If it's services (and your teammates agree) then management won't object.

What you can't do is go off on your own and say 'I think $FLAVOUR_OF_THE_MONTH is cool, so I'm going to write the entire project in that no matter who it screws up'.

If you're maintaining old code and it's crap every time you take too long tell management why (they like explanations too). They'll eventuall come around to the idea of a rewrite.

OTOH in most teams I've worked on we've had 'black-ops' projects going on rewriting the worst of the crap. Sounds risky but as long as the workload gets done they won't notice, and the look on their faces (dollar signs, mainly) when you show them a cool new interface/faster, more stable code is worth it.

Re:SOA and other acronyms...

[MikeFM]

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.

Re:SOA and other acronyms...

[revscat]

Wow.

I work for hotels.com, and I guess I'm incredibly lucky. We just completed a major re-architecting of the site, something that was actually the continuation of some smaller prior efforts. The end result, though, it that we have a very well architected site, fully OO for the booking path (i.e. search to book), a high degree of code reuse, many (but not enough by far) unit and regression tests, and code that is *fairly* well documented. It's not nearly the nightmare you describe.

The project I was on before this one was actually dedicated solely to refactoring. (The current one was technically a visual redesign, but we made it an architectural one as well.)

Now, to be sure there is room for improvement. There always is. But I am by no means ashamed of the code we have, and there are some core areas that I think are quite worthy of admiration.

Hell, there's a rumor that Expedia might utilize some of our code to replace similar functionality on their site. Considering that they only recently began the process of switching away from C, we're kind of flattered.

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.

Re:SOA and other acronyms...

[Anonymous Coward]

I come from an academic computing research background (compsci, not software engineering) but have worked increasingly with some of the big vendors' R&D teams. While I appreciate the attitude that "software methodologies" often seem to be vapor or restating the obvious, I am begrudgingly accepting things like SOA and design patterns precisely because of the reasons you mention.

These vendors are trying to support development including the weaker half of the programmer population. While you think it is impossible for those guys to apply abstraction, the vendors think it is impossible for them to apply the kind of generalized mental (and code) transformations necessary to see how all these different patterns and philosophies are just the Same Old Thing. Many of the people working on large scale distributed systems do not have the chops to do so from first principle, so these "patterns" and "architectures" and "methodologies" are produced in excrutiating detail to lead them by the nose through their development work.

There is a reason most people prefer to follow an organized software religion, rather than be an independent philosopher or areligious worker. It is human nature, and the kind of population distribution you are noticing... when they have a hammer, everything is a nail. They need a guiding book to tell them when to pick up the hammer and when to put it down. They need interpreters to help them with the hard part of the book. There's an abstraction for you... ;-)

Re:SOA and other acronyms...

[MikeFM]

That sounds exceptional. I bet it saves your company a lot of money over time. Are they making any special effort to document the change in expenses over time?

I've worked at half a dozen different companies in the web development department and none of them have done anything near that. I've worked with Perl, Python, PHP, ColdFusion, JSP, and ASP so I don't think it's just a certain group that has this weakness either. If I ever move to the Dallas area I'll have to apply with you guys as you sound like people who know what they're doing. ;)

Using C for web apps seems a really bad idea to me. It might make sense for a small portion of an app but it's such a security risk and such a pain to make changes to that I can't see why anyone would do it. I hope you're getting a nice license fee from Expedia.

I was thinking that programmers should get tips like other service workers based on how pleasing their work and service is. If your company can license out your code to others then they should give everyone on your team a bonus. :)

Re:SOA and other acronyms...

[Cally]

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.

Hate to sound like a wizened old veteran, but I am, so that's how it comes out[1]. Son, if you're giving out your home number to anyone at work apart from HR (or a possible date, if you're prepared to take that mad risk) then I'm afraid you had it coming... It's like the old army saying: Never volunteer. Never give anyone the ability to call you out of work hours, let alone 2am!, unless you're being paid a fat on-call bonus. (This should be structured such that you only get paid if they call you: if you have a flat-rate bonus for being prepared not to hang up when you realise who it is, plus some for each call-out, they'll feel entitled to call you at 2am, and that they're just getting their money's-worth. )

Whether you feel it's worth the money is your call; if it stops people from asking me whether I'd be prepared to do it, I'm all in favour.

References:
[1] Bill Hicks (misquoted)

Re:SOA and other acronyms...

[lifespan]

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
Inadequate or non-existant supervision and review of the work of juniors sounds like the problem rather than anything inherently inferior about these graduates.

Peer Review, now that sounds better than... AEP... Asychronous Extreme Programming

Re:SOA and other acronyms...

[RobinH]

I get paid a flat rate by the hour, so yes, I get paid to take a call at 2 am.

The other thing is that my cell phone is required to be on at all times, and within earshot. (This isn't enforced too terribly, but you do get sh*t if you're caught not answering.) Then, if they call my number and I don't answer, then they call the main office number, and it goes to our call center, where they will ask for me, and the call center will call my cell phone again, and finally call my home number. They have my home number because the company I work for gave it to them, and I had no friggin' clue that they were going to use it like this.

I'm tempted to change my home number, but they could just look up the new one off of the cell phone bill every month.

But, I do love the work (the stuff during the day anyway) which is why I put up with all the bad stuff about it.

yeah... no.

[chrisxkelley]

see, software reuse is definatly why we all love microsoft :-D

Re:yeah... no.

[WilliamSChips]

Software reuse is fine when the code that's being reused is good. But when it's M$-quality...

Another resource

[karvind]

The posted story has few links in the end. I remember reading another article sometime back and it addresses the issue as well, not necessarily applied to SOA (and article is/was more clear as well IMHO). From this article the main reasons are:

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.

Re:Another resource

[Anonymous Coward]

Psychological impediments -- ... In addition, the ``not invented here'' syndrome is ubiquitous in many organizations, particularly among highly talented programmers.

I've got to say, if you replace the word 'talented' with 'rogue' then you've got it. The most experienced programmers always reuse code as much as possible, by the time they're gained that experience they've realised that writing code for the sake of it isn't the be all and end all of coding.

SFs and other acronyms...

[Anonymous Coward]

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

Software Factories

SOA

[Saiyine]

SOA in the wikipedia.


--
Superb hosting 4800MB Storage, 120GB bandwidth, ssh, $7.95
Picaday!!! Strange & sexy pictures (Some NSFW!).

EYA FFS! - Expand Your Acronyms, for ****'s sake!

[grcumb]

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.

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

[Anonymous Coward]

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.

I really don't get your point. Are you mocking the manager for insisting on HTTP for transport and XML for encoding?

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.

No doubt. But people who can implement robust services and reusable interfaces are better off chosing to use standard transport protocols and encodings, like HTTP and XML, versus inventing their own. Absent obstacles that would absolutely prevent their use, one would be a fool to not use them.

Re:Same song, different verse

[MikeFM]

I agree totally. Using standard protocols is the pay to go and when picking the standard to use it's often best to pick the ones that are easiest to work with. CORBA is great but HTTP and XML have far more support and thus will be easier for other's to work with. When you have a choice pick what is well supported and lightweight. If you need the extra functionality of something such as CORBA then use it. This is why I suggest picking RDF over XML-RPC, XML-RPC over SOAP, SOAP over CORBA, etc. Always use as little complexity as is needed but no less than is needed.

Re:Same song, different verse

[Anonymous Coward]

So what would you use instead of HTTP and XML?

'cause if you're wrong about that (and I suspect you are very wrong) then your entire post seems angry _and_ stupid.

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:Same song, different verse

[cpu_fusion]

In this particular case, the integration with the trading partner could have been done naturally via an existing ECI/CICS interface, wherein transactional semantics would have been preserved. This would even have required very little coding for the bank.

But hey, that's not quite as sexy as HTTP/XML is it? Remember too this was 2000; SOAP itself had just been out since mid-1998 if I recall correctly. Online trading business-to-business isn't exactly the best time to go with the latest protocol and encoding mechanism, just because its hip.

Re:Same song, different verse

[cpu_fusion]

First off, I completely disagree that distributed objects has been discarded as unworkable. There are many CORBA and other-ORB based solutions in production today. Distributed objects works, but like anything, it won't work if you misuse it or misunderstand it.

Remember that you are free to serialize objects by value across CORBA (or RMI), and also can keep things as stateless as you desire. I don't think distributed objects and SOA are exactly the same thing. I should have stated that explicitly. SOA is a subset of distributed objects. It is distributed objects with additional restrictions. I believe that it is important to recognize that the very restrictions that makes SOA attractive for some domains may make it inappropriate for others.

What do you think a service is? It is an object. It has an identity. The identity is the provider of the service. You invoke the service, you marshall across your document (ie. a serialized object), the other side does something with it either synchronously while you wait, or you get a callback later with the results. Hey, guess what, that's distributed objects. (It's also a RPC.) A decent distributed object implementation isn't going to necessarily require that the object you are invoking be a single chunk of memory on a single server. It is going to be a virtual identity that has failover, balancing, etc. SOA is distributed objects. Distributed objects is more than SOA.

Again, SOA is just distributed objects with more restrictions; restrictions that, while nice, aren't a panacea.

You bring up EJBs; the EJB spec was fairly straightforwardly updated to support SOA. SOA is a subset of distributed objects. What happens when you need the service to keep state? Or to return something like a reference? Wouldn't it be nice if your framework helped you out with that?

Seriously, to follow your anology, this is like people running around saying the Linux kernel needs to move to C++ because OO is better than modular programming in C.

Use the right tool for the right job.

My point, again, is that people who are running around talking about SOA like it is something profoundly new need to reflect on the principles that already exist in best practices for distributed objects (e.g. in regards to reuse), and additionally recognize that the very constraints they are placing on distributed objects to create SOA may preclude use cases that are actually valuable in some domains. It would be just like the distributed objects people pretending they could close their eyes to the reality that they are doing RPC.

Re:Same song, different verse

[Bob9113]

What is the definition of an object? It is a struct with associated logic and an identity. Suppose two threads each have a reference to the same object, what does thread A see when thread B mutates the object? It sees the same mutated object. You cannot pass an object by value. There is no such thing as pass by value in OO (regardless of the fact that many pseudo-OO languages allow pass by value). You can clone an object, but then you have two objects with the same state, not one object with two identities. OO is the representation of the world in objects. Can you pass a car by value? Can you pass a planet by value? No? Then you can't pass an object by value.

As to the "discarded as unworkable" statement: Over-the-wire client server apps (and what else could we be talking about when discussing SOA?) in most any real world case fail at the network level if they incorporate true distributed objects. Fine grained method calls - pure OO - will saturate gigabit ethernet with a miniscule CPU load in all but edge cases.

Not that you should not use pass by value; it is quite practical in real-world programming, which is why it is a prominent feature of most "OO" languages. Furthermore, the entire concept of SOA is that in situations where you desire a decoupled client and server, pass-by-value is a practical solution (not *the* practical solution, not *the one true path*, just a practical solution). But pass by value is inherently not OO. There may be OO programs on each side of the bus, and the system as a whole might be generally describable as an OO system, but if the programs on each side of the bus are not sharing single identity structs with associated logic, it is a hybrid system.

As to your straw man that I am saying SOA is a panacea; I am not. If the goal is a loosely coupled client server system, SOA is a good solution, that's all.

Re:Same song, different verse

[cpu_fusion]

> There is no such thing as pass by value in OO (regardless of the fact that many pseudo-OO languages allow pass by value)

By your criteria, IIOP and RMI are not "distributed objects" protocols, which I think is rather pedantic. If that's your definition of distributed objects, then yah -- that's not going to work. Not being able to do pass-by-value would cripple a network app to the point of being unworkable. But, speaking of strawmen, there's one right there; I've never used such a narrow label for distributed objects in my previous posts here.

Ah well, we will have to agree to disagree.

Re:Same song, different verse

[Bob9113]

By your criteria, IIOP and RMI are not "distributed objects" protocols, which I think is rather pedantic.

RMI and IIOP can and have been used for distributed objects. So can any remote technology. If the client stub acts only as a proxy which passes every method call over the bus, then it is a distributed object. I am not trying to be pedantic about the definition of "distributed objects", I am trying to be pedantic about the definition of "objects".

The mindset that coarse grained method calls are just a different kind of distributed object is the whole thing that makes coarse grained method calls so hard for people who are not as skilled as you or I to implement. Seeing fine grained method calls and coarse grained method calls as concepts that live at different ends of the same spectrum is what causes many coarse grained method call systems to fail. The ambiguity of how-fine-is-too-fine leads to tight coupling between the client and server.

SOA breaks the link with objects. The first mindset shift in using SOA is that every service call involves sending and receiving documents. It is natural to think of documents as inherently temporal - their truth value is inversely proportional to their age. This means less arguing about things like, "Is an optimistic lock required?" Of course it is required, we're dealing with documents, which are inherently temporal. Calling coarse grained method calls "distributed objects" gives the less skilled practitioner the false hope that some magic system is going to ensure that state is synchronized. SOA puts it right on the table; there is no magic synchronization. You send a document, and if it lines up with the other side's view of reality, all will work as planned. If not, it will say, "I'm sorry, your document does not match my view of reality."

Not a panacea, not a magic solution for state management, just a mindset shift that makes it harder to confuse the noobs.

Mod parent up. eom.

[btobin]

eom.

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?

Re:Same old problems

[Bill Privatus]

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?

Because the APIs are not SOA. The APIs are independent of SOA. Say it with me - SOA is not an API.

A SOA does not require Java, nor SOAP. A SOA is an architecture - if you will, a "technique" of building software systems.

Because it is based on standards, there will be proliferation, and interoperability, and scale (look into the newest fledgling standard, ESB or Enterprise Service Bus - the paint is still wet, and it's not even recognized by OAGIS, OASIS, W3C, or IETF, but that will come).

For those who are not even superficially informed about SOA --- the things that SOA will be making possible are going to surprise you.

Re:Same old problems

[Todd Knarr]

You're confusing a language binding of an API with the API itself. Java's merely one language you can bind an API to. SOAP is merely one way of encoding the call's arguments and return and transporting them over the network (it does the combined job of XDR and RPC in SunRPC). SOA is, I'm afraid, another way of saying "We'll break our software into components, then have anything that needs something done call the function in the component that does that.". It's fancied-up, but it boils down to what's been taught as good design/architecture practice for the last 30 years. I've been through about 4 iterations of this so far, I don't see this one being significantly different.

Re:Same old problems

[Bill Privatus]

Let me modify my statement slightly: SOA is neither an API nor a language binding. :-)

Perhaps another manner of analogy would help. SOA is not the same as Web Services, just as Web Services is not the same as SOAP. SOAP is a very minor part of Web Services, and Web Services is a very minor part of SOA. A CICS transaction on a mainframe can participate in a SOA and provide a service that is sold to external business partners, without entailing the use of SOAP or Web Services (though it would most commonly be fronted by a web service at some point, for many reasons). If you want to provide high availability, security, auditing, metrics, and perhaps QOS for all requesting traffic, then SOA is not only your "best" choice, it may be your only choice.

In a qualitative sense, I think you understand the "flavor" of SOA. One difference between the previous generations of change you describe and SOA is that there is API-based physical requirements like "call stack" or "parameter order" - that have all been abstracted away. There is no overriding requirement for security (it's provided for in the standards as a way of abstracting away the assumed security infrastructure in past generations - and note that assumptions nearly always translate to constraints or requirements).

Monitoring and control are well on the way to becoming realities - which, to someone as experienced as you seem to be, is an important fact. The technology has found acceptance and the supporting tools and technologies are now taking shape.

Re:Same old problems

[Todd Knarr]

Things like parameter order I consider to be not particularly critical: they're often required because of the particular transport involved, but the fact they exist isn't really crucial to what's happening. RPC vs. SOAP would be an example: SOAP attaches names to parameters so physical ordering is irrelevant, RPC doesn't so it has to use order, but that minor bookkeeping difference isn't really critical.

As far as monitoring and control, yes they're well on their way to becoming reality. That's because they were reality some, oh, 20-odd years ago.

Note that I'm not saying SOA is bad. It's good, for the same reason that structured programming is good. It's just nothing new or innovative, it's just another buzzword for a good modular architecture with clean interfaces and the ability to do remote procedure calls when appropriate. And it's going to have all of the same problems we've always had with similar architectures. The big one is defining the services to be provided. Creating a general-purpose service that's useful to a lot of things (a prerequisite to reusing the service elsewhere) takes time and care. Management usually says "Why is this taking so long? We need it now, stop wasting time trying to do all those things we don't care about.". End result is you end up with the same problem you get with regular object libraries: functions that, while in the library, don't actually do what your new program needs done and so can't be reused. I don't see SOA doing anything about that problem, so I don't see SOA succeeding where it's predecessors have languished.

I think the main problem is I've seen too much. After about the 4th or 5th time I hear another generation of new people expounding the same great idea, absolutely certain that it's new and never been tried, I tend to shrug and let reality deliver the reality check. I think I hit the "Whatever." stage about when Web applications were new and going to change the world and had nothing whatsoever in common with a system where the server uploaded a form definition to the browser, which could then let the user fill in the form fields, perform basic error checking and transmit the completed form back to the server. Because no Web application could possibly be similar to an IBM mainframe and a 3270-series workstation, you see.

How about you RTFA?

[s88]

"Neither the synopsis nor the article bothered to enlighten us plebes as to what exactly SOA stands for, so I googled it..."
Here is the very first sentance of the article:
Explore the inhibitors to software reuse as they apply to Service-Oriented Architecture (SOA) and learn how reuse engineering can make a positive impact in realizing the value of SOA.

Re:How about you RTFA?

[grcumb]

Touché. On re-reading, I find that the small text at the top of the page does state that. I started reading - logically, I think - at the part marked Introduction, thinking that that was where the actual article started. My bad, though I do think a full definition, or at least a link to one, would not be out of place.

Thanks for the LART, though. Serves me right for skimming.

Re:How about you RTFA?

[Gooba42]

How about writing an accesible and compelling write-up so that those of us who don't already have an interest in or knowledge of SOA might see a point in reading the article?

SOA was utterly opaque to me and I wasn't going to bother to read the article since the write-up doesn't make any meaningful connection to the subject but now having read a definition in the comments I might read the article since it has relevance to something outside itself now.

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.

Re:Not gonna work

[Tony Hoyle]

I used to have a manager that used to ask 'is it generic?' every time we discussed something.

Unfortunately for him generic meant 'solves every problem, even ones I haven't thought of yet'. Hugely complex APIs were designed, filling a bookshelf.

As you can imagine, some of the modules that were in use were utterly horrendous... months were spent writing routines that could do *everything* even extremely unlikely things. There were functions that were 2500 lines long, mostly switch statements on the input (I'm not exaggerating.. I had to debug them).

Sure they had code reuse. Unfortunately for them, the code sucked. I remember spending a couple of weekends resurrecting some of their ancient stuff (before the 'generic' fad) which was neat, small and well written, classing it up, and dropping it into the new code... which miraculously started to work about 10 times faster with fewer bugs.

Sure, the interfaces had to be changed over time.. *horror of horrors* the database interface layer only had 10 useful functions not 350 useless ones! How could it be generic!!! I reckon the time gained by not trying to second guess what you'll possibly need in 5 years was more than worth it.

I guess what had happened there was that 'code reuse' had become more of a mantra than a tool for getting product out of the door. I reckon it won't be the last time I see it.

Re:Not gonna work

[DannyKumamoto]

"This generates more code than reusing someone else's library, but may save development time."

This may make business sense if one can count on the ever expanding virtual memory.

On the other hand, if you are forced to work with minimal memory or even fixed memory (e.g., embedded systems with limited ROM or Flash memory), you can't afford to generate more code for faster development. You may have to rewrite to share better, but you won't get extra ROM/memory space to keep generating more code (some devices like smart cards can't have added memory while for other systems, adding more memory means more real dollars per kilo or megs of memory -- multipling that with thousands or multi-million devices will easily kill the profitability of a product).

Re:Not gonna work

[Anonymous Coward]

1. Creating good interfaces is hard.

That quite true. That's why people should forget about finding definite solutions. Start with something that works and prepare yourself to revise frequently. That's called refactoring and that's essentially an evolutive process for pinpointing good interfaces.

2. Reusing code will not necessarily save work.

I literally despise code reuse because it forces you to look backward, or at the very least forces you to stay jammed. You either stay stuck with the code you accepted as a compromise or you accept that improvements will need to be backported. My preferred strategy is: scavenge the code you need and refactor to your liking. If your code is any good, the refactoring by others is minimal and "code factorization"* (which I prefer to refactoring) is achieved.

*Code factorization happens when you stop splitting and generalizing and stability is attained. Code reuse is then a byproduct.

Re:Not gonna work

[cmorriss]

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.

By "development" I assume you mean the actual programming which on most large projects only takes about a third or less of the total effort. Most of the effort is spent on testing and fixing defects in the code. When you reimplement something, that means it must be completely retested and is likely to have a lot of defects that would not exist in reused code.

This is a very important reason for reusing code and why companies spend so much effort on it. The less new code there is in a product, the fewer the defects and the overall time spent will in general be less.

Re:Not gonna work

[Bill Privatus]

More FUD. SOAP is an API. CORBA is an API (and more). SOA is not an API.

You don't "create" interfaces for SOA. You choose the correct granularity for a business service/component such that it can serve requests, without the need for state or context, from not just the local executing process in memory, but from anywhere within the enterprise.

And, when you specify the business service/component in such a way that it can serve requests, without the need for state or context, from anywhere, you now have the ability to turn software development from a cost center into a profit center (read: from anywhere, even outside the enterprise).

Regarding your second point - "easier" to reimplement and then refactor (!!!), if in your experience this is true, then all I can say is that XP (extreme programming) and SOA are going to be two huge wedges driven into the already-large chasm between the Cathedral and the Bazaaar - because SOA-based reuse will very likely turn out to be orders of magnitude more productive and profitable (ROI) than "refactoring" - especially after "reimplementing"!

SOA not only will work, it is already working. Companies are saving millions of dollars. Projects estimated at 6 weeks are getting done in 3 days. Projects estimated at days are getting done in an afternoon. Not all projects, of course (before someone "wisely" points this out). But...the world is changing. I could go into "business benefits" but that's not an approach I've seen used successfully on /. in the past...

Wait for it. The tools are coming or are already here - from all the major players (except Microsoft, but they cannot stop this juggernaut & will eventually join the rest of the bleeding-edge-world --- they've already come around in providing robust, genuinely-working .NET-to-Web Services interoperability with J2EE products).

Re:Not gonna work

[Chemisor]

> By "development" I assume you mean the actual programming which
> on most large projects only takes about a third or less of the
> total effort. Most of the effort is spent on testing and fixing
> defects in the code.

I don't know where you work, but on my projects there's no difference between the two. You can not separate "actual programming" and "testing and fixing defects" because you should do them concurrently. Implement a feature, and it goes to the testers; then you start on the next one while they are running tests and other programmers submit their features/bugfixes. Then testers find something that doesn't work and file a bug report. You fix the bug, resubmit, and the cycle continues. If you find yourself needing a special "testing" cycle, you're doing it wrong. Without continuous testing and feedback you'll just keep digging yourself into the hole; deeper and deeper.

Biggest challenge: get an architect who knows his

[Anonymous Coward]

I work in a large shop where the lead "architects" have confused SOA with serialization. The result is like watching a train wreck in slow motion. Even though it is a homogeneous MS shop and all services are internal, the standard is that typed-objects (even data only objects) shall not be passed between services. Instead all methods on all services shall have exactly 1 parameter which must be a proprietary, untyped "business object" serialized into byte array, thusly in one fell swoop violating almost every best practice known to mankind. Imagine 100+ services mapped to 1000+ databases with no objects, no datatypes, no schemas, and no versions. Just method calls with a single parameter byte-array parameter from which the caller must extract data by name then cast it to the appropriate datatype.

At least the consultants will get rich re-writing the whole mess when it gets thrown out.

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:Use is better than re-use.

[dcw3]

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

Bravo! I'd love to hear how other software engineers balance their schedule (too short) and budget (too little), with the need to do it by the book? As an engineer, I'd love to get all the UML diagrams & ICDs & design documents just right, but that's often the last thing that management (and frequently the customer) cares about, and as such gets the short shrift on the schedule (when in my opinion, it would make the code time fly by).

More closely related to the topic at hand, I just attended a briefing on "Web Services". The model shown was virtually identical to the one we used for CORBA, with naming service registration and all...seems like the same stuff with a new buzzword (now us old C++ guys have to go learn Java...*cry*), and new security & performance concerns. If someone knows (and can explain clearly) why this is better, I'd like to be enlightened.

Software use and reuse

[Jerry Coffin]

First of all, I guess the obligatory grouch that this really doesn't seem to qualify as much in the way of news (the cited web page is almost a month old, and it's basically a combination editorial and sales pitch, not an announcement of anything new or revolutionary).

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

Re:Software use and reuse

[Anonymous Coward]

Looks like IBM has mastered Service Oriented Articles

Re:Software use and reuse

[Bill Privatus]

This is the longest rant I think I've ever seen that was composed based on zero knowledge of the technical subject at hand, but rather on some kind of on-the-fly interpretation of the three words "service" "oriented" and "architecture" used in juxtaposition.

Your points:

1. [...]being "service oriented" is roughly as new as dirt.

   See above.

2. how in the world this would relate to software reuse

   SOA makes software reuse not only easy but unavoidable - through tooling. See my other posts here for other thoughts in this vein, including use of ESB (Enterprise Service Bus).

3. ...they haven't really told you anything about how to facilitate reuse in general, or how SOA is supposed to contribute to that...

   Interesting. What else have you tried to read besides this sales-oriented (I call it marketecture ) web page? Any actual technical articles?

Here, try these:
Service-oriented architecture - Wikipedia
webservices.xml.com: What is Service-Oriented Architecture?
Service-oriented architecture (SOA) definition
.NET Architecture Center: Service Oriented Architecture (see what Microsoft has to say about it)
Loosely Coupled monthly digest -- July 2004 (ESB)
ESB Fills Management Gaps for Web Services

Re:Software use and reuse

[Jerry Coffin]

This is the longest rant I think I've ever seen that was composed based on zero knowledge of the technical subject at hand [ ... ]

Sorry Bill, but if you'd bothered to read what I said, you'd realize that this was simply incorrect. In point of fact, to anybody who didn't know better (and nobody but their authors do for sure) it could easily look like at least two of the papers you cited were based on the background portion of an article I published critiquing one of the first attempts at an ESB spec.

See above.

Making, and later referring back to an ad hominem attack isn't exactly the stuff of deep technical discussions, now is it Bill?

SOA makes software reuse not only easy but unavoidable - through tooling.

Nonsense. While you can (and people are certainly trying to) create tools that make software reuse easier, the simple fact of the matter is that anybody who wants to can avoid just about anything they choose. SOA is mostly about specifying some interfaces -- but just using an interface can't (and certainly shouldn't) force anybody to use any particular piece of software for a particular job. As long as that remains true, reuse remains avoidable. Not only is it avoidable, but as long as it does remain avoidable, it will be avoided under some circumstances by some people, sometimes for better and others for worse, but inevitably it WILL happen. If somebody were to attempt to make some level of reuse truly unavoidable (i.e. make it mandatory to use specific pieces of software for particular jobs) then it would really become more easily avoided than ever -- because at that point, nobody with any intelligence whatsoever would even consider using SOA at all.

Interesting. What else have you tried to read besides this sales-oriented (I call it marketecture ) web page? Any actual technical articles?

Your question seems to entirely miss the point. I was critiquing the article in question, and pointed out that it contained virtually nothing about how SOA was supposed to contribute to software reuse. Your reply seems to indicate that you somehow believe my having read other articles would somehow affect the content of this one. If there was any logic involved in reaching that conclusion, it has utterly escaped me.

It doesn't surprise me when my post bothers an enthusiast. It does, however, dismay me when the enthusiast can't put up a better defense than "Your refusal to extoll the wonders of my favorite technology indicates obvious ignorance."

--
The universe is a figment of its own imagination.

Re:Software use and reuse

[Bill Privatus]

Let's see if I can respond without adding to the level of testosterone, then, as you've fairly obviously laid bare my passions :-)

Your statements appeared, given their narrow focus, to be short-sighted and to "entirely miss the point" of the larger issue of SOA. Your longish foray into reuse bled into statements regarding SOA in other contexts, yet was entirely based on the single web page you found.

It's not that this is my "favorite technology". But, there is much positive about it, and its arrival edges us closer to that day when architects design systems and business people then put together applications. Whether that day is tomorrow or 20 years from now.

I don't agree that my comments constituted an ad hominem attack, but if that's how you perceived them then I apologize.

"I was critiquing the article in question, and pointed out that it contained virtually nothing about how SOA was supposed to contribute to software reuse."

What I read in your statements was a condemnation of SOA in general before you were done, though you certainly started on the topic of reuse.

While you can (and people are certainly trying to) create tools that make software reuse easier, the simple fact of the matter is that anybody who wants to can avoid just about anything they choose.

Perhaps an unfortunate choice of words on my part. I used similar words in another post last night, and was called out on it there too, so I'll concede the point. However, note that the intent of SOA, and CBM, and ESB, and SOMA...is that there is policy, and enforcement, in addition to "tooling", a loaded term with which I intended to convey much more than just development tools, IDEs, or small utilities.

I have a solid technical foundation in SOA and related technologies as a J2EE architect; yet, I'm still a diehard UNIX admin and security guy. Nonetheless, I see the reality of what's coming with SOA, and it's going to be fascinating to live through it.

What is SOA?

[KarmaBlackballed]

A Service Oriented Architecture (SOA) is a software implementation that delivers information services via loosely coupled interfaces that are accessible by non-proprietary tools and products.

Not just like all others.

[KarmaBlackballed]

SOA is a "hot" acronym for an old and valuable idea. An SOA approach emphasizes a loose coupling between components of a system. When done right, the result is a solution that is more adaptable to changes because a change in one component does not necessitate changes in others. (Examples of tight couplings include systems where SQL queries are embedded throughout all components. Change the database and you need to change a lot.)

The most obvious example of SOA is Web Services, but that is just using specific set technologies to deliver an SOA solution.

Something special about the Web Services approach is that the vehicle for the loose coupling between components is XML. Unlike some other technologies, it is possible to involve subject matter experts rapidly and usefully in XML design because this can be done with minimal instruction. (We are not talking about creating DTDs or XSDs here, just the functional content and hierarchy of the communications.)

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

Getting smart people collaborating on a project is a great idea no matter what the methodology. (Methodologies are a poor substitute for talent.)

Re:Not just like all others.

[MikeFM]

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.

Re:Not just like all others.

[Tony Hoyle]

In other words... ye olde 80's style modular programming. Whether it's XML or a .lib file it's still a module.

Why not call it that... we've buried good style in acronyms these days. I've seen stuff written by otherwise good programmers that makes me want to tear my hear out and scream - new programmers often aren't taught to think in terms of small, discrete objects, less still layers (I'm big on layering... it's saved my bacon more than once.. you can tell any project I've been on for a while because structurally it starts to look like a layer cake... plus I get a reputation for being able to implement the silly spec changes without breaking everything...).

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.

Genericness

[Tablizer]

The problem I find with trying to make something generic is that every new usage tends to need somewhat different features that have to be added. After a while the generic thing becomes a huge packrat of features, yet the quantify of features used by any one usage stays roughly the same. Thus, the interface and implementation grows too huge to be practical. It becomes easier to borrow code as-needed rather than deal with the maintanence of a huge generic thing.

Re:Genericness

[Estanislao Mart�nez]

The problem I find with trying to make something generic is that every new usage tends to need somewhat different features that have to be added. After a while the generic thing becomes a huge packrat of features, yet the quantify of features used by any one usage stays roughly the same. Thus, the interface and implementation grows too huge to be practical.

Ah, but then I'd argue that the thing you built is not truly generic. It's factored wrong.

It's a very common flaw, which one finds all over the place in OO design--interfaces that are just too damn big, do way too many things, and therefore are (at best) a pain to implement when you need a meaningful subset of the functionality.

One of my favorite examples is the Java Collections API, whose interfaces in general provide too many interaction protocols that a collection class must implement. So God help you if you want your, say, straightforward singly-linked list (à la Lisp), to implement the java.util.List interface. You'll need to implement all sorts of extra stuff to make it work, even though little of it responds to the protocol that is used to interact with such a list (last-in-first-out, direct access only to the head of the list).

In general, you should only define a generic interface when you have some generic algorithm that doesn't care about the details of the objects it operates on, as long as they provide operations X, Y and Z. And even then, your interface should only require operations X, Y and Z.

Or another way of putting it: ideally, the argument and return types of public methods in your classes should as a general rule be interfaces that declare only the actual methods that your class's implementation calls, and these latter should be small in number.

Or even simpler: if it ain't small, it ain't really generic.

Re:Genericness (correction)

[Tablizer]

yet the quantify ...

Should be "quantity" not quantify

Code reuse is simple

[Anonymous Coward]

Most recent language platforms are designed around code reuse. Ruby, Python, Java, C++, PHP, Perl. Classes, OOP. It's simple, really. You just have to be willing to learn something new.

The benefit of OOP / reusable code design doesn't always come in dragging a big blocky module from one app to another. It comes in smaller elements of reusable code. Check out 'Design Patterns' - it's sort of a guide to developing modern reusable code.

Re:Code reuse is simple

[Todd Knarr]

I learned C++ and object-oriented programming when cfront was the implementation of choice for it. I also picked up "Design Patterns" 10 years ago when it first came out, and not a lot in it was new to me (although it was nice to have it all in one place and nicely laid-out). Ditto "Antipatterns", which I found equally useful.

Of course, when I was just learning C++, I also opined that it'd be a great language... in 10 years or so when they'd finally shaken it down and figured out how to use it right. I'd submit that my prediction was not inaccurate.

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.

YATLA...

[Anonymous Coward]

Dammit, last time I checked, SOA was "Start of Authority"... and I didn't understand how the HELL DNS was tied in with this programming crap! :D Wasn't this "eXtreme Programming" last year?

Hey, Slashdot Editors and Submitters: ETFTLA*s, please?

*Expand The Fucking Three Letter Acronyms

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.

Re:SOA drawbacks

[Cederic]

These are all fair points. That's why the architecture must be carefully managed.

However, in practice, you will have different functionality being provided by different teams. You will often have functionality provided by different COTS systems.

If they all focus on provided services according to a document SOA architecture, that makes re-use of those services and integration into other services considerably simpler.

It wont solve the issues you've raised - but it'll solve a lot of others.

Sure, SOA has flaws. It's also just a simple term describing the current industry best-approach to handling complex enterprise environments.

Of course.

[Estanislao Mart�nez]

Unfortunately for him generic meant 'solves every problem, even ones I haven't thought of yet'. Hugely complex APIs were designed, filling a bookshelf.

Indeed. Something generic should be applicable to problems you haven't thought of, but not to everything. And the fewer methods an API demands that you implement, and the less they do, the more problems you can apply it to...

SOA is programming for managers

[rpcxdr]

SOA is basically programming for managers. It pushes the level of reuse up to a management level.

Mark my words, SOA is only valuable if you can identify the business value in each of your components. SOA is not for software architects alone to create - it must be made hand in hand with your business analysts and executives. Otherwise, its just a software play. And like many of you have pointed out, another layer of software is no silver bullet.

SOA can be applied to a human bank teller service as well as it can be applied to an information service: Modularizing any company, weather through software interfaces or business unit interfaces, makes it more agile. Supposedly, if done right, SOA can bring about a very profitable merge between software and the business.

For you, OP with acronyms expanded...

[Sometimes_Rational]

Developers: Reuse Engineering for Society of Actuaries

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. The Society of Actuaries 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."

SOA very popular

[LazloTheDog]

It seems that most companies already use SOA (Sales Oriented Architecture).

JM

SOA is goodness but ...

[Stu Charlton]

... I think you're overreacting. There's a lot of reason to be skeptical and critical of SOA, especially given the hype. Having said that, since SOA is an IT-management focused opportunity, Slashdotters are not particularly inclined to really value or understand it, nor should they.

The market is around US$10B this year, and according to Gartner (IIRC), it'll be US$95B in the next decade or so. That's Billion with a B.

That estimate, IIRC, is for the entire integration marketplace -- SOA or no, and I believe it's projected a few years out. It's also a bald-faced estimate, also known as a crap shoot. And Gartner's batting average is certainly not above .500.

Reuse under SOA is virtually guaranteed - because the tools are graphically assembling the underlying services.

Working for one of the aforementioned software vendors in the SOA marketplace, I make a living talking to CIO's about this stuff. I would get thrown out by my ear in 5 seconds if I suggested that reuse is due to some kind of drag 'n drop GUI. That's patently ridiculous, and almost a cliche'. Angle-brackets and better data transformation / routing tools aren't going to bring about the reuse nirvana; you're just going to have a more maintainable set of "web services" that are marginally re-usable.

To get to re-use, you need to sort out tremendous business process, organizational, political, governance, semantic, and data quality issues. It's a slog along very non-technical lines. Sure, the newer products help, and it's arguably the last roadblock to make it palatable to the visionaries -- but It's going to be the long slog that enterprise data warehouses were in the early to mid 90's, which I believe was the last successful wave of business-oriented re-use.

Recall that most organizations failed to build out an enterprise data warehouse, they just wound up popping marts & cubes everywhere, except for the cream (Amazon, Best Buy, Wal-Mart, a few Telcos, a handful of Banks). Similarly, not many orgs are going to succeed in changing their IT departments to a services-oriented world view; those that do will take years and it will be due a lot less to product or consultants than to the vision of their leaders.

Re:SOA is goodness but ...

[Bill Privatus]

Working for one of the aforementioned software vendors in the SOA marketplace, I make a living talking to CIO's about this stuff. I would get thrown out by my ear in 5 seconds if I suggested that reuse is due to some kind of drag 'n drop GUI. That's patently ridiculous, and almost a cliche'. Angle-brackets and better data transformation / routing tools aren't going to bring about the reuse nirvana; you're just going to have a more maintainable set of "web services" that are marginally re-usable.

There are (chiefly) two ways to realize SOA - bottoms-up and top-down. Bottoms-up involves "organic" growth, where those closest to the data & functionality develop services, services which are sooner or later adapted into the more formalized structure that is created via top-down methods. It's possible to garner most of the benefits of SOA by bottoms-up methods - but not all. Reuse is difficult (as you and everyone else have pointed out), but it's by no means impossible!

And, yes, you would likely get thrown out on your ear by making an obtuse statement that a GUI would be the sole reason for reuse. On that point we agree. Please note that "supporting tools" need not be as simplistic as, nor restricted to, a "GUI".

LOL

[Anonymous Coward]

This subject, SOA, always makes me grin.. since in Dutch it's the abbreviation which is equivalent to the English 'STD'.

Reusing engineering for sexually transmitted diseases? The things they come up with noways ;)

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.

Reuse depends on modularity.

[master_p]

Code written intentionally for reuse (for example, the Java libraries) can be re-used again and again and again, without a problem: coupling is low, interfaces are clean and consistent, documentation is good.

Code written in the context of an application can not easily be reused, due to the couplings with that particular type of application.

The problem is even harder in commercial and enterprise application environments, where requirements change daily: the end code is usually a very high performance but poorly constructed piece of software in software engineering terms, and thus it can not be easily reused.

SOA can not help you if the code to be reused (even if in the form of services) does not fit 100% with your requirements.

No, SERVICES re-use.

[$ASANY]

This article entirely misses the point of a SOA. If the purpose of SOA is to enable the creation of multiple instances of the same object in different applications, then worrying about code reusability would be warranted. But that's not what SOA is all about. You want to reuse the services that are created in a SOA, consolidating common functionalities into services that are shared by different "applications". Once you "get" what SOA is, the next logical step is net-centric where we stop duplicating applications and start creating reusable architectures. We create enterprise services (such as authentication, data discovery, business processes, etc.), and those are re-used, not the code that created them. And then if you're really good, you start moving towards Enterprise Architecture. I thought IBM was this good.

I can't imagine what sort of nitwit is going to try to use the same language and coding construct across all the systems in an enterprise, which is what code reuse will require. Maybe the best way to code your web app is in python, but the RFID system needs to be written in C, and the business process monitoring is a Mercator or Unwired Orchestrator dashboard. You can either put developers into bondage and mandate .Net for everything, which will yield universally mediocre results but excellent code re-use, or you can use the best tool for the job at hand and worry about service architectures rather than development minutae. Guess where the best business value lies? Guess where you end up creating a dynamic, interesting and challenging development shop that doesn't swap out key staff every 18 months?

IBM usually has their head on straight with SOA, so I'm rather surprised with this article. Seems like some of their people have wandered off the reservation and fallen into a deep ravine.

Write it properly the first time

[Digital_Quartz]

If you find yourself needing a special "testing" cycle, you're doing it wrong. Without continuous testing and feedback you'll just keep digging yourself into the hole; deeper and deeper.

Umm... no. First of all, testing cannot fix problems. Testing cannot guarantee the absense of defects. All testing does is tell you how good your software is, quality wise. If your testers find 100 defects per hour of test effort, then your software is total crap. Even if you fix all the bugs the testers find, there's still tons left, and you'll never "fix" them all. If your testers find very few defects per unit effort, then you know your software is very good, and is ready to be released into the wild for your customers to use.

Second, the parent was correct; it may be faster in terms of development time to rebuild rather than reuse, but it is definately not faster in terms of your product's overall lifecycle. For every hour you spend implementing something, you spend either a few hours elsewhere in design and code inspection, or in a company like yours, several hours in test and repair. All you have to do is not insert defects into your codebase to begin with, and then you really won't have to spend much time in test at all. This is very easy to do.

If you're not catching the bulk of your defects long before you reach test, then either you are in a very high margin buisness, you need some serious process improvement, or else you should just save yourself the trouble and pack up shop now, before you hemorage any more cash.

Listen, son

[Cally]

...you won't get far in the world of corporate development with your book-learnin' and fancy college talk. Abstract an API and document it to enable code reuse? W're a Microsoft shop, goddammit!

Disclaimer: I must admit that I have had to maintain some of the most god-awful Perl ever imagined... suffice to say the author's previous experience was 40 line NT batch files and some crippled home-computer BASIC that made a lot of use of GOTO. *shudders at the memory*...

I wonder if that code's still being used to test and release that mega-corp software vendor's anti-virus product signature updates...