The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

SOA: Emperor has no clothes?!

Interesting viewpoint: Perhaps the most hyped up acronym in the technology world is SOA, Service Oriented Architecture.

http://blogs.ittoolbox.com/emergingtech/technocrat/archives/soa-emperor-has-no-clothes-11339
MB Send private email
Monday, August 28, 2006
 
 
SOA wasn't the first, it won't be the last.

Keep in mind that the tools business is an extremely profitable business. Unfortunately, it's not a sustainable business in the sense that you can create a set of tools and then live off of them for the next 30 years. Ergo, next year they'll try to sell you a better tool and the year after that, an even better tool.
TheDavid
Monday, August 28, 2006
 
 
The article doesn't really have much to say and doesn't convince me.

In my opinion SOA is a very powerful approach in some situations. I worked on a SOA project that allowed a rather well-known auction site - yes, you know the one - to connect to the services of another large organisation. I was impressed at how easy and useful SOA was in this approach. We could ensure that the auction site always had access to latest information. SOA needs a well-defined interface, and therefore we were forced to be disciplined and do this. SOA apps are highly unit-testable, because web services use a "put this data in, get that data out" type of interface.
Steve McLeod Send private email
Monday, August 28, 2006
 
 
"SOA needs a well-defined interface, and therefore we were forced to be disciplined and do this."

I think this was probably of more value than the SOA technology itself. I will cede the point and admit that it may not have been possible to frame the discussion without SOA, but if you were willing to roll up your sleeves and put in a lot of blood, sweat and tears, you probably could have accomplished (what I think you accomplished) through enterprise level Java beans.
TheDavid
Monday, August 28, 2006
 
 
"SOA requires well-defined interface" does not imply "well-defined interface requires SOA".

SOA does contain some good practises, but is enormously over-hyped by those who make this basic flaw in logic.
Mike S Send private email
Monday, August 28, 2006
 
 
The original link posted here is total crap. I'm certainly no SOA fanboy and I'm personally quite tired of hearing about how it is going to magically solve everyone's problems. But the author gave no real concrete reasons why SOA is over-hyped. If you are going to make such a claim then back it up. SOA should be an easy target. So why did he miss so badly?
anon
Monday, August 28, 2006
 
 
SOA has its pros and cons. It is certainly no silver bullet but it does work well in certain situations.

1) SOA works best for discrete functions with no dependencies. Unfortunately, the real world doesn't always work this way. The classic examples of services are things like inventory lookups, stock prices, and credit authorization. These are simple request/response functions. But things like "hiring an employee" do not fit this model. They require more complex orchestrations and data models. It can still be done but it gets painful very quickly.

2) Everything is coupled. Saying that you want loose coupling still means that you have at least "some" coupling. The goal is to be coupled on an interface. Not an implementation. For example, changing the web service's message format/parameters is guaranteed to require a modification on the client side. No technology in the world could get around that. But changing the DBMS vendor on a coporate system shouldn't cause a client program to need modification. SOA helps in this scenario.

3) People often confuse SOA with Web Services. I get tired of architects who insist on Java or .NET web services when there is already another communication mechanism in place. Leverage what you have if it makes sense. Buying expensive Enterprise Service Bus products just to pass a couple of simple messages back and forth is complete overkill. Especially when many shops are already have HTTP servers sitting around serving up content. Yes, you can write a "service" using nothing more than classic JSP, PHP, or ASP pages. It may not be the best route long term but if you are already using the technology in-house, why not save those dollars for something worthwhile? Like new laptops for the development team... ;)
Turtle Rustler
Monday, August 28, 2006
 
 
the author have me at his name Mohan Babu K...Babu, for real?
TripleDots
Tuesday, August 29, 2006
 
 
I work on a SOA platform (http://www.reardencommerce.com), where the architecture makes sense. I agree, though, that it is overly hyped and too powerful (and heavy-weight) in most cases. For us, it works perfectly as it improves scalability and allows us to easily integrate new services into a common platform. SOA works here, where you're driven to rapidly develop new services and create a rich experience by leveraging core information (e.g. user information).

Most articles I've read on SOA seem to limit it to a single service and confuse it with webservices. The idea of a service bus isn't new, nor asynchronous workflows. Most of the time they get too caught up in making a pure SOA and the constant refactoring of its guts. In reality, most of your time is spent adding value on-top of it - not arguing about platform semantics. The ability to have have multiple stove pipes and not be tied to any single silo is what's important. The rest is just jargon.
Manes
Tuesday, August 29, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz