Attempted SOA will cause great successes and great failures of software projects. Understanding its role and meaning, beyond the simplistic hype, is the imperative for every enterprise software architect.
Service-oriented architecture (SOA) was first described by Gartner in 1996 (see SSA Research Note SPA-401-068 SPA-401-069 , 12 April 1996, "'Service Oriented' Architectures, Part 2"), but the recent interest in the architecture has been spurred by the emergence of a powerful industry trend: Web services. Although Web services do not necessarily translate to SOA, and not all SOA is based on Web services, the relationship between the two technology directions is important and they are mutually influential: Web services momentum will bring SOA to mainstream users, and the best-practice architecture of SOA will help make Web services initiatives successful.
SOA and Web Services: Two Complementary Talents
The definition of "SOA" is discussed in detail in "Introduction to Service-Oriented Architecture." Essentially, SOA is a software architecture that starts with an interface definition and builds the entire application topology as a topology of interfaces, interface implementations and interface calls. SOA would be better-named "interface-oriented architecture." SOA is a relationship of services and service consumers, both software modules large enough to represent a complete business function. Services are software modules that are accessed by name via an interface, typically in a request-reply mode. Service consumers are software that embeds a service interface proxy (the client representation of the interface). Web services are defined elsewhere in Gartner research (see "The Web Services Provider Platform: You Already Have One" and "Introducing Common Sense to Web Services" ). Simply speaking, any software that uses the standards Web Services Description Language (WSDL), Simple Object Access Protocol (SOAP) or Universal Description, Discovery and Integration (UDDI) is a Web service.
As evidenced by the definitions, Web services are about technology specifications, whereas SOA is a software design principle. Notably, Web services' WSDL is an SOA-suitable interface definition standard: this is where Web services and SOA fundamentally connect. Those who see Web services as architecture regard WSDL as the definitive standard of Web services (others see SOAP as a definitive standard for Web services — this is a view of Web services as a communication method). In practical use, the ubiquitous Web services standards enhance the mainstream appeal of SOA design. Through 2008, SOA and Web services will be implemented together in more than 75 percent of new SOA or Web services projects (0.7 probability).
The Best Use of SOA Is for New, Multichannel and Composite Real-Time Applications
SOA is gradually replacing monolithic architecture as the premier design principle for new business applications. This process is driven in part by the inherent benefits of SOA for new application projects (see "Predicts 2003: SOA to Stir Up Application Server Market" ). However, several recent developments in the software industry have helped to bring SOA further to the forefront. With personalized client/server, Web-based and portal-style user interfaces, an increasing number of projects require reuse of application business logic over multiple access channels. Different user categories (operators, customers, mobile sales staff, self-service employees, managers), in different situations (office, home, road, hotel) and using different devices (personal digital assistants, phones, laptop computers) all may request access to the same essential set of back-end business functions. The loosely coupled SOA provides the natural basis for unintrusive reuse of the back-end logic by multiple styles of clients. Thus, the transition to multiclient and multichannel applications naturally pushes forward the SOA-based application design (see "Predicts 2003: SOA Comes of Age via Web Services" ).
Another fundamental trend in application engineering is the reuse of older and external applications in new user-facing transactions. The composite application style has emerged as an alternative to the development of all-new applications. In fact, in 2003, the majority of new business applications have some connections with external resources and thus are composite applications. Many projects have created programmatic interfaces to wrap legacy and other external functionality for assembly into heterogeneous composite transactions. Composition and integration of old and new business components into new real-time transaction patterns are a natural fit with SOA.