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.

Downsides of SOA?

What are the downsides of Service Oriented Architecture?
John Topley Send private email
Thursday, December 08, 2005
Well, to the extent it involves SOAP (as SOA nearly always does), it means a ton of extra processing overhead.
Thursday, December 08, 2005
& network overhead
Thursday, December 08, 2005
And its a solution in search of a problem.

I get the impression that they've decided the current way of communicating between various applications is broken (which to be fair, is true), and they believe this new framework and set of rules will magically fix everything.

I'd say 99% of the time, the system is broken simply because no one has ever sat down and tried to properly design everything to work together. Or to put it another way, the current tools are good enough. Now you just need a business analyst to determine where to connect things using the available the tools.

If I misunderstood what SOA is supposed to be about, please enlighten me.
Anonymous Coward
Thursday, December 08, 2005
SOA should be a way to build new business processes on top of a set of services built integrating existing legacy systems. Unfortunately SOA tools, usually based on BPEL, are seen by customers (read: IT managers of non-IT companies who don't have a clue and don't know what are they talking about) as a way not to write code and not to hire decent programmers ("hey, I can draw lines and boxes instead of writing that inextricable code I can't understand").

EAI and SOA requires very skilled software architects, otherwise they simply downgrade to a bunch of inefficient SOAP calls and another, usual waste of money...

mkj6 Send private email
Thursday, December 08, 2005
It's just one more layer of abstraction. If you like lots of layers in your architecture, then I say go for it.

I was involved with an SOA project at a previous employer, and the architecture was something like this:

Every user request was cought by a request handler, which would create an Action object (a concrete class which subclassed the AbstractAction class). The action class would call certain methods from an appropriate service handler class. The service handler was written as a class that implemented a certain service interface (a ShoppingCartImpl, for example, implemented the ShoppingCart interface). The concrete service class would then build a Model object containing all of the business data necessary for the service to perform its actions. The Model object was constructed by instantiating the appropriate DAO class, which would construct objects using an ORM framework (in our case, Hibernate), which would connect to the database through JDBC.

After the Action performed the correct Service method on the Model, and the DAO wrote the new application state to the database, the Action would dispatch to the View tier. In order to determine the appropriate View to generate, the Spring dependency-injection framework would parse an XML file and then determine which view-dispatcher to instantiate (using reflection). In nearly all cases, we used JSP views to display the results of the operation to the user. So a collection of POJOs would be passed into the request scope, and the JSP would render a page for the user.

If that sounds like a reasonable architecture to you, then by all means, dive into an SOA project.

Personally, I think it's absurd.
BenjiSmith Send private email
Thursday, December 08, 2005
The downside is that they've reinvented CORBA, only with a whole lot of XML and HTTP added in to overcome any hint of efficiency.  ;)  To be fair, various proposals for regular TCP connections and binary-XML will eventually get them pretty close to having a full CORBA implementation.

The big justification for HTTP is that it's easier to use HTTP than to persuade system admins to open another port in the firewall, which really ought to be making someone nervous.

Heh, one of the fun problems with CORBA was that making object access transparent means that people write code to run over the internet and test it with the 'remote' objects in the same address space as the caller, so they don't get an entirely accurate perception of the performance issues, and never take the time to design the system to account for the laws of physics and bandwidth limits.

Gee, I can't imaging that happening with SOA, right?

Thursday, December 08, 2005
What does SOAP have to do with SOA? Are two acronyms being mixed up? BenjiSmith's wonderfully elaborate example didn't involve SOAP.
YaYaYa Send private email
Thursday, December 08, 2005
I'm curious as to what the response time to a user request is in BenjiSmith's example
Matt B Send private email
Thursday, December 08, 2005
The real problem of an SOA is not having any control (or even influence!) over the end points you're using.  If something goes down, what happens?
KC Send private email
Friday, December 09, 2005
One downside is, that in Dutch SOA stands for Venereal Diseases. That makes that most people can't hold their laughs when this term is used...
Friday, December 09, 2005

I don't know any exact performance metrics, but in general, the performance was pretty poor.

Our app could handle only 20 or 30 simultaneous users before it would slow to a crawl. And we were hosting the app servers on pretty high-powered hardware. We also had the database server hosted on a different box than the app server.

Of course, this was during our beta testing of the application, and I don't think anyone had spent any time profiling and optimizing yet. It's been six months now. Maybe they've improved performance.
BenjiSmith Send private email
Friday, December 09, 2005
Downside: SOA assumes that you can break your application/system up into discrete services. We all know that that is simply not always possible. However, that doesn't mean that you can't just break some functionality off into separate services. I think that this is where people get tripped up. They think that SOA is an all or nothing proposition. That simply isn't the case.
Turtle Rustler
Friday, December 09, 2005
And Benji's example shows my point taken to the extreme.
Turtle Rustler
Friday, December 09, 2005
The trouble with SOA, in my opinion, is that it sounds so reasonable.

I want to add a product to my shopping cart. That's an action that I'm performing, so I send a request to the server invoking an AddProductToCardAction.

The AddProductToCartAction is one action out of many that will interact with my ShoppingCartModel, so it makes sense to have one service layer that provides all of the methods that my actions will need in order to interact with the model.

The ShoppingCartService needs to interact with the objects in my cart, and those objects are represented in the ShoppingCartModel class, which uses the database (through an ORM DAO interface) to persist those objects between page requests.

The real problem with SOA is that it makes a lot of sense.

Unfortunately, in my opinion, it's almost always overkill. Although the process of adding an item to my shopping cart can certainly be represented as such, it can be done so much more simply, with less computational overhead, and with fewer layers of abstraction.

But the reason SOA is so seductive is that it makes sense.
BenjiSmith Send private email
Friday, December 09, 2005
"But the reason SOA is so seductive is that it makes sense."

Well...  you need to travel at least 25 miles a day commuting from home to work, and your hours are such that you cannot carpool or ride the bus.  It makes sense to buy a car.  It doesn't make sense to buy a $220,000 Ferrari F430 Spyder.  :)

There are such things as good ideas that are just simply too expensive (by whatever measure of cost) to implement.

Incidently, if you happen to be an employer and a Ferrari sounds like the best solution, I want to work for you!
Anonymous Coward
Friday, December 09, 2005
SOA has its place and as has been mentioned it rarely if ever will be an all inclusive proposition.  Most SOA I have seen makes sence in theory but completly breaks the KISS rule.  Heck atm I am reporting to an ex-programmer turned head architech and manager that turns everything into a winning Rube Goldberg submisson.

Don't expect to last long. I keep disagreeing politly with him and turning out robust and stable things that don't have to be babysat by a developer to run.
anon for safty
Friday, December 09, 2005
Thanks everyone!
John Topley Send private email
Monday, December 12, 2005
LOL.  So much so true :)

I recall ACM's Queue magazine was launched with the teaser that issue 1 would include an article entitled "Web Services are just CORBA with a Weight Problem".

I was looking forward to that article but strangely (yeah, right) it never appeared.  I wonder why.
Abstract Typist
Tuesday, December 13, 2005

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

Other recent topics Other recent topics
Powered by FogBugz