Common misperceptions about SOA

You'll often hear about the shift in mindset required to fully adopt SOA. The myths we tackle here only scratch the surface of the change that's in store for those firmly entrenched with traditional architectural views. Our focus in this section is to dispel the most common points of confusion about SOA and the use of the term "service-oriented."

3.3.1. "An application that uses Web services is service-oriented."

This comes down to how SOA is defined. As we've established, there is a distinction between SOA as an abstract model and SOA based on Web services and service-orientation. Depending on which abstract model you use, almost any form of distributed architecture can be classified as being service-oriented.

To realize the benefit potential of the mainstream variation of SOA we've been discussing, you need to standardize how Web services are positioned and designed, according to service-orientation principles.

So whether this statement is a misperception or not actually depends on your expectations. A traditional distributed architecture can be called service-oriented as long as the benefits associated with primitive and contemporary SOA are not expected.

3.3.2. "SOA is just a marketing term used to re-brand Web services."

Certainly the term "SOA" has been (appropriately and otherwise) used excessively for marketing purposes. It has become a high-profile buzzword, riding the wave of hype brought on by the rise of Web services. The fact that contemporary SOAs are being implemented using Web services has led to some skepticism around the validity of the term itself. Some believe that "SOA support" is just a re-labeling of "Web services support."

SOA is not an invention of the media or some marketing department. SOA is a legitimate and relatively established technical term. It represents a distinct architecture based on a set of distinct principles. It just happens that contemporary SOA also implies the use of a distinct set of technology used to realize fundamental SOA principles. The technology platform of choice is currently Web services and all that comes with it.

3.3.3. "SOA is just a marketing term used to re-brand distributed computing with Web services."

There are many people who believe this, which has led to the "false SOA" syndrome explained in Chapter 1. The reasons behind this myth are understandable. Much of the hype surrounding SOA has overshadowed its actual meaning. Additionally, many of the migration paths laid out by product vendors blend traditional distributed computing with Web services, accompanied by advertised "SOA support." The results certainly can be confusing. Further, the validity of some promoted SOA support is questionable at best.

However, SOA is its own entity. It consists of a set of design principles that are related to, but differ significantly from, the distributed computing platforms of the past. We compare SOA characteristics to distributed computing in detail in the following chapter.

3.3.4. "SOA simplifies distributed computing."

The principles behind SOA are relatively simple in nature. However, applying these principles in real life can prove to be a complex task. Though SOA offers significant benefit potential, this can only be realized by investing in thorough analysis and adherence to the design principles of service-orientation.

Typical SOA implementations require more up-front research than solutions created under previous platform paradigms. This is in part due to the broad Web services technology platform imposed by contemporary SOA.

The quality of simplicity surfaces later, once service-orientation is established and standardized within an IT environment. Then, when integration requirements emerge, when a sufficient number of composable services exist, and when service-orientation principles are well integrated into an organization, that's when SOA can simplify the delivery of automation requirements.

3.3.5. "An application with Web services that uses WS-* extensions is service-oriented."

While the entire second generation of Web services specifications are certainly driving SOA into the IT mainstream, simply making these extensions part of an architecture does not make it service-oriented. Regardless of the functionality with which Web services are outfitted, what makes them part of a service-oriented architecture is how the architecture itself is designed.

Having stated that, though, it is expected that most solutions that seriously employ the use of WS-* extensions will, in fact, be service-oriented. This is partially because the adoption rate of SOA is anticipated to roughly coincide with the availability of WS-* extension support in development and middleware products.

3.3.6. "If you understand Web services you won't have a problem building SOA."

A technical and conceptual knowledge of Web services is certainly helpful. However, as we established at the beginning of this chapter, fundamental service-orientation principles are pretty much technology agnostic. Service-orientation requires a change in how business and application logic are viewed, partitioned, and automated. It therefore also requires that Web services be utilized and designed according to specific principles.

Web services are easily incorporated into existing traditional distributed architectures. There they can be centrally positioned and assigned significant processing responsibilities, or they can be appended as peripheral application endpoints.

The manner in which Web services are utilized in SOA is significantly different. The emphasis placed on business logic encapsulation and the creation of service abstraction layers often will require a blend of technology and business analysis expertise. It is best to assume that realizing contemporary SOA requires a separate skill set that goes beyond a knowledge of Web services technology.

3.3.7. "Once you go SOA, everything becomes interoperable."

The media attention and marketing push behind SOA has likely contributed to this myth. Many assume that by virtue of building service-oriented solutions, their technical environments will naturally transform into a united, federated enterprise.

Though this ultimate goal is attainable, it requires investment, analysis, and, above all, a high degree of standardization. By leveraging the open Web services communications framework, service-oriented architectures (and service-oriented integration architectures) naturally abstract and hide all that is proprietary about a particular solution, its platform, and its technology.

This establishes a predictable communications medium for all applications exposed via a Web service. However, it does not automatically standardize the representation of the information that is exchanged via this medium. Therefore, as SOAs become more common, there will be good and not so good implementations. A quality SOA requires that individual services conform to common design standards for federation, interoperability, reusability, and other benefits to be fully realized.