The Good, the Bad, and the Ugly of Service-Oriented Architecture
page 6 of 7
by Tom Fuller
Average Rating: 
Views (Total / Last 10 Days): 38948/ 54

The Ugly

Most of what I have determined as “ugly” in SOA is, unfortunately, very expensive to an enterprise. Much of the issue is related to the newness of service orientation, and, as is often the case, the most costly aspect of introducing new technologies and concepts is the investment in your company’s human capital. People are resilient and, in some cases, are very agile, but that agility comes with time and experience.

One of the most challenging roles in the service-oriented era is that of the quality assurance engineer. Most services are designed to satisfy the needs of various applications; that makes their requirements somewhat fragmented. QA experts need to understand the internals of all applications that are potentially impacted by a service. Services boundaries, when designed explicitly, can be tested in isolation, but changes and versioning will introduce the need for sophisticated regression testing cycles. QA experts need to understand how one application can change the behavior of another application that depends on that same service they are testing.

Another not-so-obvious added cost with service orientation is the complexity involved in the test environment setup. As applications begin to bind themselves to specific versions of reusable services, those services will need to be set up and made available for testing as an application goes through a normal release schedule. This creates a need for isolated installations and numerous versions of the same services. It also creates a need for quite a few more servers and hardware. The cost comes from the complexity in managing and supporting all of these varying installations of the same services.

I already started to hint at my next major SOA money pit. Versioning with first generation web services is extremely challenging. DLL hell seems to have resurfaced in the WSDL world. Depending on the design strategy, method signatures can create a scenario where changes are all but impossible without impacting the consuming applications. Some strategies have surfaced like message router solutions and message type strategies, but all of them have significant drawbacks.

Another major problem with versioning of services is any implicit semantic contract changes. Any behavioral changes to an exposed service can negatively impact consuming applications. It is not always fair to say that what a service does not know does not hurt it. Consumers could potentially depend on things like error conditions or failure scenarios in previous versions of the service. Syntactic and Semantic contract versioning is very complicated with web services in their current state.

As service-oriented applications begin to move to production environments, control of these reusable services is typically transferred to a production support group. This introduces a new challenge for resources that are responsible for high-availability, distributed systems. Somewhat like the QA engineers, production support engineers often have to become experts of all dependent applications for a service they might be responsible for. The key measurement of success for any production support professional is responsiveness. Without understanding all of the other dependencies, it can be a challenge to even find the root of a problem.

As with other distributed technologies, it becomes more challenging to trace application code at runtime and quickly do problem determination on systems that live on numerous servers and sometimes on disparate platforms. These issues are amplified when applications are not designed with durability and supportability in mind.

The final additional cost to an application delivery timeline is the negative impact service orientation will have on developer productivity. It’s really impossible to take away all of the implicit benefits of a development platform and not see an impact. Earlier we discussed coding to the lowest common denominator. This also becomes true of the standards and best practices for the developers in an enterprise SOA.

I am confident that, over time, developers will overcome the complexity of developing web services that are interoperable, and I’m sure that we’ll see the tools continue to catch up. If you plan to build web services today, these costs are unavoidable but temporary. The productivity costs that will never subside are the needs for detailed documentation. Any reusable component comes with an increased need for clear API definitions.

View Entire Article

User Comments

Title: Project   
Name: Dude MaN (for protection)
Date: 2007-10-11 10:07:28 AM
hey i am doing a report on the pro and cons on Architecture can u help me.
Title: RE: Great article, but Moore's Law?   
Name: Tom Fuller
Date: 2005-09-01 10:00:55 PM
Just realized I was cut off when I posted my response. Sorry for taking so long to notice......

I think we'll see in the future that if the services that are intended to stand the test of time are delivered as tightly coupled portions of a business application then those services will in the long run lose any level of autonomy (which would be another one of those tenets).

This has been at the heart of almost every discussion I've had with people about SOA lately and I plan to write another article in the upcoming weeks titled "SOA Design Strategies: Adhering to the 4 Tenets". This will go into detail on these very issues we are discussing.

Thanks again for taking a look at my article and I appreciate your criticism.
Title: RE: Great article, but Moore's Law?   
Name: Tom Fuller
Date: 2005-08-30 10:05:45 PM
Thank you for the feedback. I have to admit the loose application of Moore's Law in the article has come under some crticism. What I will say is that I did not intend to say poor design was justified through my use of Moore's law in the article. I really wanted to use it more as a high level comparison to show that there is little to no doubt that the capabilities of our hardware and infrastructure will only continue to increase. It is that increase that could neutralize any of these minor performance concerns with SOAP based transports and message serialization. This does not mean that you can completely dismiss performance concerns today but SOA will continue to focus on delivering loosley coupled systems that can last longer than the applications we delivered in the past. That in my mind means we should consider the potential capabilities of the network and the hardware that these systems will depend on.

The rest of your comments seem to focus on the design issues surrounding service orientation and they are certainly valid. It is too often the case that common layered architectures fall into the trap of future proofing everything that is built because of the constant pains associated with versioning. This comes back to an issue of agility in your software delivery process. I know this is easier said than done but, the fact remains, if there was no concern that services could be delivered outside of the natural release schedule of an application then you could avoid this "Field of Dreams" approach you talk about.

You have also made a very powerful statement below and that was, "some sort of agreement on what the service is all about should be reached". This covers two of the critically important tenets of SO. You are talking about boundaries being explicit here and that services exchange contracts and schema not objects and types. I think we'll see in the future that if the services that are intended to stand the test of time are delivered as ti
Title: Great article, but Moore's Law?   
Name: TravelMonkey
Date: 2005-08-29 12:25:20 AM

A great article overall!

However, I was a bit dismayed by the fact that you seem to use Moore's Law (or a variant thereof) as a scapegoat to allow for poor performance today. I may be stretching what you said a bit, but you seem to imply that somewhat adequate performance from SOA is OK today, because Moore's Law will take effect and in 18 months things will be better.

Has Moore's Law been extended to include networks now? I have not done the math, but I would say it's a reach to say that it has held true for our bandwidth.

At any rate, I would advocate creating the best performing design and code you can today, and leave Moore's Law as a nice theory, not an excuse if you can't make good performing code. SOA doesn't NEED to be poorly performing, though I think poorly written web services have doomed it with that stigma at times, to some purists. I think an "outside the firewall" scenario does allow for some "slop" in the code, as one expects slower performance out in the cloud due to network latencies beyond our control. However, for an intranet app, the SOA needs to scream. Internal users are far less forgiving of slow performance.

I also don't think SOA implies poor performance--I think poor design implies poor performance. Spend some of the expense of SOA on ensuring your design meets good performance standards from the beginning; you'll save money in the long run by making apps that perform today.

I think another potential money pit that needs to be examined is to ensure that you don't get bitten by the "Field of Dreams" scenario. You know--"If you build it, they will come." I don't feel that SOA is about that. Make sure service consumers are in place (a real need is identified) and that some form of contract is in place. I'm not necessarily advodating contract-first, but some sort of agreement on what the service is all about should be reached.

Your article is a great overall view of SOA, I think. Well done.

Title: Nice article   
Name: user
Date: 2005-08-25 2:50:40 PM
Really nice condeptual article. Can you give real time example where some company is already using SOA.


Product Spotlight
Product Spotlight 

Community Advice: ASP | SQL | XML | Regular Expressions | Windows

©Copyright 1998-2024  |  Page Processed at 2024-07-15 4:55:52 PM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search