back to article Eclipse gets Fishy on SOA

The Eclipse Foundation's plan to push ahead with a Services Oriented Architecture (SOA) run-time framework later this year marks an interesting change of direction for the industry group. The Swordfish project, announced last summer, has now reached level of maturity where it can be evaluated and its significance assessed. …


This topic is closed for new posts.
  1. Anonymous Coward
    Anonymous Coward

    Again, a post by someone who doesn't have a clue...

    Seems like tech writers are sometimes so desperate for something, anything to write, that they forget that their audience tends to be more educated on the subjects they cover than they are.

    1. Talking to anyone at JBoss about a competing architecture/product/idea is pointless. Not that JBoss is a horrible team/company/division, but they do have a little bit of a problem with anyone else coming up with something good...

    2. Eclipse is based on OSGi; the simple fact is that quite a few people have been looking at a server-side framework based on OSGi for some time now, and for this to come as a surprise, or to be interpreted as anything relating to the so-called SOA hype is plain idiotic.

    3. SOA is really nothing by hype, but some of the technologies in that space aren't; and they are making significant inroads.

    Tech Writer = Moron is a tautology.

  2. Anonymous Coward


    Why so personally hostile? The article is a bunch of questions and not statements of fact. Maybe you could have joined a discussion and not bulldozed it into a possible mud fight. :(

  3. Nathan Meyer

    The Trouble With Orchestration

    Good luck with the fish.

    The "SOA" concept has been around since I started working in the trade 24 years back. The principle stumbling block I have observed is that if you make the Data and Business Services reusable, then they must be non-contextual and low function. This has several knock-on effects. First the intelligence of the transaction is driven to the Orchestration layer, which is the only level that knows the context of the transaction and the meaning of events within the transaction. All transaction logic, relational edits and data locks must be maintained at the Orchestration layer. This produces performance problems, deadly embrace and data corruption, as the Orchestration layer has to make multiple calls to multiple services and hold data locks over an extended period of time. Concurrency issues are crippling. These are the issues at the heart of why SOA is of questionable utility.

    Also consider that re-use is the primary cost justification for SOA. Surveys reporting the most optimistic levels of re-use (and organizations that just made massive investment in a concept will always rate the results of that investment as positively as possible) claim 10% to 40% re-use. That's not much return on investment, now is it?

    Third, like all Objet D'art styles, one generally ends up breaking out business functions into atomic services. This process is often difficult, and has to be re-visited constantly, as the granularity of the service doesn't map to the business definition of a transaction. The first change order affecting a widely used service can pull down the entire edifice.

    Fourth, the internal and external security issues of SOA are very disturbing. Function re-use too often leads to people having access to data they don't need and should not see.

    It's all very well to say that internal reviews will catch these issues, but in reality it is too easy for say, Hospital Housekeeping staff, tapped into the ADT system for room cleaning purposes, to end up viewing confidential patient records. The lack of context at the Service and Data levels also makes it easier for external hacks to take advantage of those data services once past the walls.

    Last, let us speak again of dismal performance. The additional overhead inherent in the multiple messaging required to pull the various bits of the transaction together, and the addition of a text-based parser in the SOAP/XML scheme cannot help but add to that.

    This is not to say that there are no applications that would benefit from the SOA version of orchestration; rather that we cannot assume that this is any more of a magic wand solution than CORBA, TUXEDO or DAF were.

  4. Anonymous Coward
    Black Helicopters

    It's very simple, really

    It's really not hard to understand why SOA hasn't taken off. It's too complex. And complexity is the #1 killer of all projects. It scares away innovation (for many reasons, for example it's hard to prototype SOA projects quickly and cheaply), it makes management nervous (the spectre of being hit for $$$ is ever present, e.g. to buy an entirely new tool chain, test tools etc). And the work you end up with is just too complex for humans to understand, which means you are at the mercy of your tools (and the smarts of of the poor schmuck who must maintain this code for the next 10 years).

    No. Successful projects use techniques and protocols that are small and lightweight, and can be protoyped rapidly. That's why Visual Basic was such a killer product when it came out, why Perl succeeded in the early days of the web, and why we are still using SMTP 20 years after RFC 822.

This topic is closed for new posts.

Biting the hand that feeds IT © 1998–2018