Re:Service Oriented Architecture is your Ticket to Hell
by wwhchung on Friday August 31, 2007 @05:34PM
(#48985)
The article's statements on the problems with SOA don't accurately reflect reality. For example, "SOA requires you to do a whole load of up-front design and specification that's very difficult to change after." This is not a problem with SOA, rather than a symptom of poor change management, which can occur in any code base whether you are using SOA or not. Similarly, his "strange loops" issue is really an issue of poor dependency management/mapping. You can easily write a program that exhibits the same problems.
One valid issue with SOA is data consistency. Dealing with data consistency across services is a real problem, and this may contribute to extra development time. But by no means does this indicate that SOA is the opposite of agile. There are agile development benefits in SOA, and I don't feel that the drawbacks outweigh these benefits.
Re:Service Oriented Architecture is your Ticket to Hell
by arasakik on Friday August 31, 2007 @04:40PM
(#48951)
While the article makes some interesting points about the perceived flaws of SOA, I'm not sure that I agree that they are specific to SOA itself. Perhaps some of them only apply depending on the context of the situation.
His first point with respect to the up-front design needed for service interfaces - how is this any different when creating any public API that other services will consume? This is a challenge for any public interface. If the interface needs to change, mark the relevant sections as deprecated.
The second point with respect to strange dependencies - this could certainly be a problem with disparate services spread across many organizations. Again, I'm not certain that this issue is specific to SOA - it sounds like the author is pointing out that finding relevant documentation about service dependencies is the flaw here. Again, I'd like to point out that this is a challenge for any project calling on other code - documentation could be distributed across many different open source libraries, etc.
SOA definitely has its benefits. Companies such as Amazon.com have scaled successfully because of their Service Oriented Architecture, before it became a buzzword.
One valid issue with SOA is data consistency. Dealing with data consistency across services is a real problem, and this may contribute to extra development time. But by no means does this indicate that SOA is the opposite of agile. There are agile development benefits in SOA, and I don't feel that the drawbacks outweigh these benefits.
His first point with respect to the up-front design needed for service interfaces - how is this any different when creating any public API that other services will consume? This is a challenge for any public interface. If the interface needs to change, mark the relevant sections as deprecated.
The second point with respect to strange dependencies - this could certainly be a problem with disparate services spread across many organizations. Again, I'm not certain that this issue is specific to SOA - it sounds like the author is pointing out that finding relevant documentation about service dependencies is the flaw here. Again, I'd like to point out that this is a challenge for any project calling on other code - documentation could be distributed across many different open source libraries, etc.
SOA definitely has its benefits. Companies such as Amazon.com have scaled successfully because of their Service Oriented Architecture, before it became a buzzword.
The author is correct, though, in stating that a lot of the buzz around SOA is bullshit. This is typical of any method/solution that receives a lot of hype. For example: http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile...