Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Programming Software IT Technology

Reuse Engineering for SOA 124

Posted by ScuttleMonkey from the don't-reinvent-the-wheel dept.
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."
This discussion has been archived. No new comments can be posted.

Reuse Engineering for SOA More

Reuse Engineering for SOA

Comments Filter:

  • Software reuse. (Score:1, Insightful)

    by milhous3030 ( 761677 )
    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. (Score:2, Interesting)

      by 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. (Score:5, Insightful)

      by AutopsyReport ( 856852 ) on Sunday October 02, 2005 @06:14PM (#13700657)
      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.

    • Electronics reuse. (Score:1, Funny)

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

    • Re:Software reuse. (Score:2, Interesting)

      by nzNick ( 721082 )
      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)

    • 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. (Score:4, Informative)

      by cpn2000 ( 660758 ) on Sunday October 02, 2005 @06:27PM (#13700711)
      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. (Score:2, Interesting)

      by 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. (Score:5, Insightful)

      by turkeywrap ( 560320 ) on Sunday October 02, 2005 @06:40PM (#13700752)
      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. (Score:3, Interesting)

        by Javagator ( 679604 )
        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 writte

        • 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

    • Re:Software reuse. (Score:4, Insightful)

      by MikeFM ( 12491 ) on Sunday October 02, 2005 @07:11PM (#13700867) Homepage Journal
      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. (Score:3, Interesting)

      by Tony Hoyle ( 11698 )
      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 l
      • Comment removed based on user account deletion
      • 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

    • 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.
      • 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();
    • 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 [wikipedia.org] where we stop duplicating app

  • Acronym Expansion (Score:1, Informative)

    by Anonymous Coward
    SOA - Service-Oriented Architecture

  • Ok, I've worked all day and I'm grumpy, but ... (Score:5, Funny)

    by John Jorsett ( 171560 ) on Sunday October 02, 2005 @06:11PM (#13700642)
    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.

  • SOA is not a magic bullet (Score:4, Insightful)

    by Anonymous Coward on Sunday October 02, 2005 @06:14PM (#13700654)
    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).

    • 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

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

        • 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 ar

    • 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

  • SOA and other acronyms... (Score:5, Insightful)

    by RobinH ( 124750 ) on Sunday October 02, 2005 @06:17PM (#13700671) Homepage
    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... (Score:4, Insightful)

      by trawg ( 308495 ) on Sunday October 02, 2005 @06:45PM (#13700767) Homepage
      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 :)
    • 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 s
      • 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 main
      • 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 str
    • 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.
    • 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
      • 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
        • 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
          • 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 b

            • 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 peop

    • Re:SOA and other acronyms... (Score:4, Insightful)

      by The Famous Brett Wat ( 12688 ) on Sunday October 02, 2005 @07:34PM (#13700978) Homepage Journal
      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. [nutters.org] 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... (Score:4, Insightful)

        by RobinH ( 124750 ) on Sunday October 02, 2005 @09:37PM (#13701392) Homepage
        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.

        • 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 a

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

  • Another resource (Score:4, Interesting)

    by karvind ( 833059 ) <karvind@NoSPAM.gmail.com> on Sunday October 02, 2005 @06:25PM (#13700694) Journal
    The posted story has few links in the end. I remember reading another [wustl.edu] 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.

  • 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 [google.com] 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 da

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

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

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

  • Same song, different verse (Score:4, Insightful)

    by cpu_fusion ( 705735 ) on Sunday October 02, 2005 @06:35PM (#13700739)
    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 (Score:5, Insightful)

      by Bob9113 ( 14996 ) on Sunday October 02, 2005 @09:01PM (#13701265) Homepage
      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.
      • 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 i
        • 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.
          • > 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 d
            • 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 dif

  • Same old problems (Score:5, Insightful)

    by Todd Knarr ( 15451 ) on Sunday October 02, 2005 @06:52PM (#13700783) Homepage

    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?

    • 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 bas

      • 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 ta

        • 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 commo

          • 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

  • Not gonna work (Score:5, Insightful)

    by Chemisor ( 97276 ) on Sunday October 02, 2005 @06:57PM (#13700801)
    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.
    • 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
      • 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...

    • "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 l

    • Re:Not gonna work (Score:1, Insightful)

      by 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 ac

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

      • > 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 w
        • 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 s

    • 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 ha

  • Biggest challenge: get an architect who knows his (Score:1, Insightful)

    by 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 e

  • Use is better than re-use. (Score:4, Insightful)

    by smileyy ( 11535 ) <smileyy@gmail.com> on Sunday October 02, 2005 @07:02PM (#13700822)
    Software designed for re-use will likely never ship, or ship far later than software designed to do something.
    • 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 m

  • Software use and reuse (Score:3, Interesting)

    by Jerry Coffin ( 824726 ) on Sunday October 02, 2005 @07:04PM (#13700834)
    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

    • 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 thou

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

        • 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

  • Read that in Dutch (Score:2, Insightful)

    by 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 [google.com] shows what I mean.
  • 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.
    • yet the quantify ...

      Should be "quantity" not quantify
    • 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

  • 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 managem

  • SOA drawbacks (Score:4, Insightful)

    by pcraven ( 191172 ) <[moc.ylimafnevarc] [ta] [luap]> on Sunday October 02, 2005 @08:41PM (#13701191) Homepage
    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.

    • 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 seems that most companies already use SOA (Sales Oriented Architecture).

    JM

  • UNIX haters discover UNIX (Score:5, Insightful)

    by idlake ( 850372 ) on Monday October 03, 2005 @04:38AM (#13702606)
    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.
  • 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 poo

Slashdot Top Deals

C'est magnifique, mais ce n'est pas l'Informatique. -- Bosquet [on seeing the IBM 4341]

Close