Welcome!

SOA & WOA Authors: Jerry Melnick, Liz McMillan, Esmeralda Swartz, Andreas Grabner, Paige Leidig

Related Topics: SOA & WOA

SOA & WOA: Article

SOA or DOA

Web applications built on a service-oriented architecture (SOA) promise to greatly improve IT efficiency

Web applications built on a service-oriented architecture (SOA) promise to greatly improve IT efficiency and business agility. SOA establishes data and protocol standards so that existing internal and third-party application modules or services can be reused and orchestrated into business applications. Unfortunately, while SOA enables the rapid implementation of business applications, it also greatly increases the complexity of managing performance when these applications are deployed in production – often diminishing the benefits of the SOA adoption. Without an effective way of monitoring application performance, and quickly diagnosing and correcting problems, there is a high likelihood that an SOA application could be dead on arrival (DOA).

There are several aspects to implementing SOA that makes it difficult for IT to manage application performance:

Slowest Common Denominator: The service level of an SOA application is limited by the service level achievable by the worst-performing services it touches on the network. For maximum flexibility, services can even be supplied by third-party vendors and may be running on different computing platforms. This makes it virtually impossible for IT to characterize the performance of constituent services or control the numerous moving parts that can affect application delivery and performance. Reusing services also means that performance flaws found in common services are replicated across applications, creating multiple points of failure. As a result, it’s very difficult to determine quantitatively if the service level exceeds end-user expectation or, at a minimum, meets the performance targets stipulated in service level agreements (SLA).

Rube Goldberg Machines: For a Web-delivered SOA application, it is also difficult to quickly determine the existence and source of service delivery problems. Culprits can include any of a myriad “moving parts” in the delivery mechanism, such as the client’s PC, the Web cloud, the data center, the composite services, and/or third-party service provider’s services or infrastructure. No list of “likely suspects” can possibly be exhaustive enough for such a complex environment.

The Tangled Web: The task of diagnosing SOA application performance problems is further complicated by the lack of a predictable or pre-determined path a particular transaction takes when traversing though the application or infrastructure. Unlike client/server computing where, for example, an inventory lookup is routed through a defined network segment and is served by an ERP application installed on a fixed physical server, that same inventory lookup in an SOA environment can be routed dynamically through the Web cloud, and be served by multiple virtual or physical servers on multiple logical tiers of the infrastructure. A third-party Web Service call might also be initiated to a supplier’s infrastructure to account for any inventory en route from the supplier’s factory. This complex orchestration involving a non-deterministic transaction path makes re-creating and diagnosing performance problems very difficult.

More Stories By Hon Wong

Hon has served as CEO of Symphoniq Corporation since its inception. Prior to joining Symphoniq, Hon co-founded NetIQ, where he served on the board of directors until 2003. Hon has also co-founded and served on the board of several other companies, including Centrify, Ecosystems (acquired by Compuware), Digital Market (acquired by Oracle) and a number of other technology companies. Hon is also a General Partner of Wongfratris Investment Company, a venture investment firm. Hon holds dual BS in electrical engineering and industrial engineering from Northwestern University and a MBA from the Wharton School at the University of Pennsylvania.

Comments (1) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Chris Weiss 06/04/08 05:11:53 AM EDT

This article exaggerates the performance and troubleshooting problems with SOA. Most of the time, simple logging is sufficient for identifying performance problems and transaction failures. Any technology that is misused will have performance problems. If a centralized orchestration platform is used (ESB, process controller, orchestrator, etc.), this piece of a SOA application can usually provide more than enough trace information to deal with problems.

The biggest problem with SOA is its overuse. Enterprises must identify "sweet spot" applications for SOA technologies. Otherwise, "traditional" application integration and construction methods work better. For example, instantiating an object and calling a class method is much faster than coupling two layers of an application with a web service call.

For client applications that place the orchestration on the client side, this is a mistake. Mash-up approaches are not appropriate for applications where transaction failures have real consequences. One of the serious mistakes in the application of SOA is to use Web 2.0 web interface analogies in the the lower layer of business technologies. However, a well written application that isolates orchestration away from the presentation layer can be monitored, measured and tracked and done so relatively easily.

Pragmatic SOA with structured design patterns used up front can get around many of the issues the author has identified. Sloppy spaghetti code without a coherent architecture in any platform will always be troublesome.