Service-Oriented Architecture

Service-oriented srchitecture (SOA) is an often-used term in today's IT organizations. Some surveys have shown that half of all Fortune 500 companies are actively pursuing an SOA in some form or another, many instituting it as their fundamental design concept.

SOA is not something that you can simply buy off the shelf, but rather is a process and architectural mindset that enables a type of IT structure to be put in place. The SOA technical design approach focuses on organizing business systems as reusable components, not as fixed processes. It potentially requires coordination with many parts of the organization and is a continuous process that changes the way IT technologies are developed and used.

Definition
There are many definitions of SOA; however, most definitions center around application functionality that can be discovered and reused through loosely coupled, standards-based interfaces. One of the more focused definitions comes from CBDI Forum, which states that SOA is:

Policies, practices, frameworks that enable application functionality to be provided and consumed as sets of services published at a granularity relevant to the service consumer that can be invoked, published and discovered, which are abstracted away from the implementation using a single, standards-based form of interface.

Other definitions may reference "network-available software units" or "business-level services," yet these are essentially different ways of describing the same concept.

SOA environments are typically highly decentralized, with physically fragmented application functionality located throughout an organization (see Figure1). These services are discoverable and accessible by service consumers. Service interfaces are abstracted from the back-end applications, decoupling interface from implementation details such as application type and operating system. Back-end services still require context and relevance to the service consumer for them to be reusable. Exposing hundreds and thousands of services does not constitute an SOA until those services are "user-friendly" or "SOA ready" to the calling applications and with the appropriate infrastructure capabilities, such as security, monitoring, interoperability, and standards support attached to them.

An Old Concept Revisited?
SOA's focus on reusability is not a new concept and has been around for years. Notable attempts at achieving cross-system reusability include CORBA and DCE. They similarly had standardized interfaces and were callable by any application that similarly followed those standards. One might argue that most middleware products are SOAs; however, this implementation approach requires everyone to use the middleware vendor's set of proprietary interfaces as the "standardized interface."

Reasons why these technologies never hit the mainstream included:

• They were difficult to use and required a high level of expertise to coordinate and implement.
• They focused on exposing programming-level objects, not business-level components.
• They implied an underlying programming model and were difficult to implement on top of a wide variety of legacy systems.
• They did not have a standard that had total industry-wide support.
• The approach tended to take significant time to implement, be very expensive and most importantly was very brittle.

One of the key principles of SOA is loose coupling, which allows the architecture to remain flexible and agile. These past approaches can certainly be described as SOA, but often were so tightly coupled that they were applicable only to the most high-end and expensive of projects.

Along Came Web Services
The standards that are synonymous with Web services are changing the playing field. XML, SOAP, WSDL, and UDDI serve as the cornerstone of Web services and are dramatically lowering the cost of deploying standardized interfaces within and across the organization. Integration technology is now available at the grassroots level, enabling application developers and even casual desktop users to fully leverage value-added services. The fact that there is significant progress on standards and a virtual monopoly of supporters from the vendor and SI community are significant drivers to the success of Web services and SOA. Early success stories from end users and the commitment shown by developers and architects have made Web services and service orientation a foregone conclusion.

What Does All This Mean?
Many analysts and thought leaders in the industry believe that SOA is the next big wave to hit IT organizations. What is all the hype about?

A convenient starting point occurred several decades ago (see Table 1), when mainframe systems brought automation and computing power to companies. Complex and core data processing, which were central to the organization, could be offloaded to these expensive machines with large monolithic applications. Mid-range computers allowed many organizations and even individual departments to leverage computing power to suit their needs. The client/server revolution brought computing power to the desktop. This mirrored changes in the organization, where individual employees become knowledge workers and needed the tools and capabilities to do their jobs. The architecture changed to become more two-tiered with server applications providing the heavy lifting and processing while the application logic moved to the desktop. A top-down approach called CASE methodology became a popular methodology for creating applications.

In the past decade, Web-based technologies and thin clients have driven the agenda, putting business logic back at the server while also providing application access to a much broader base, including every worker, partner, and customer relevant to the organization. Around the same time, object orientation was bringing component-based technology to developers building applications. SOA is the next big revolution based on previous standards like SGML, XML, and HTTP. SOA enables application access and reuse throughout the entire organization.

Some have described a massive change in the way IT organizations will operate. Just as moving from mainframe to client/server dramatically changed the IT organization, SOA is predicted to cause a similar disruption. Back in the early 1990s, client/server architecture became highly popular with skills required for database, thick-client applications and client/server network technologies. During the Web revolution, experts in application servers and Web-oriented technologies became highly valued as applications became available to a wider audience. In the SOA world, many are predicting that there will be additional specialization in creating and managing components and assembling and reusing them.

Why Do We Need SOA?
SOA has many benefits, the most common rationale of which are flexibility and agility. The fact is that SOA enables you to respond to change better, faster, and cheaper. Many organizations have recognized that in order to best align IT with business needs, they need technology systems to match and respond to the needs of the business units. The pace of business and the challenges associated with competition, increasing customer service, mergers and acquisitions, and outsourcing require a flexible architecture that is adaptable to changing needs. This agility must also minimize the constraints of cost, time to market and technology risk (see Figure 2).

IT organizations that deploy SOA gain efficiency by enabling application developers to quickly assemble applications from different available components. This not only saves time and money by reducing duplication, but also encourages a consistency in business process because as services are reused, process, to some extent, is also reused.

SOA also reduces dependence on vendors supplying monolithic solutions. Rather than having to choose one vendor for a fully integrated solution or platform, IT can more easily select best-of-breed technology to solve their needs. Monolithic application suites are predicted to be much less common given that a services-based architecture breaks up the "stovepipes" and enables companies to reduce their reliance on one vendor and customize applications to their business requirements.

IT organizations are moving to SOA so that they can better address the realities of business today, which is all about being able to handle change. Changes can be long term activities that are proactively pushed by the organization or unexpected changes that require immediate action. An SOA environment is flexible, adaptable, and designed to handle change.

What Is Needed?
Unfortunately, you can't simply purchase SOA or deploy SOA by having a few meetings. SOA requires discipline, organization and the right tools to deploy effectively and maintain it going forward.

From an organizational and process standpoint, some best practices include:

• Creation of a centralized forum for exchanging plans and information on services
• Policies and incentives that encourage developers to create services, and for business units to reuse services
• Tracking and regular evaluation to determine usage patterns and to allocate funds appropriately
• Obtaining skill sets in component management and assembly

In terms of tools and technologies, Web services standards help considerably with the need to institute standards-based interfaces. Web services, however, does not equal SOA. While Web services solves some important interoperability issues, its networks increase in complexity over time and can result in complicated connection points, redundant infrastructure, and inconsistency (see Figure 3).

Web services provides some of the following benefits:

• Separation of interface and implementation
• Support for standards-based interfaces
• Support for mechanisms to dynamically discover and bind to services

However, SOA environments have many requirements above and beyond the use of Web services. These include:

• Separation of application business logic from operational infrastructure functionality.
• The need to address security of new componentized architecture and prevent uncontrolled access to every service.
• Address unreliability of service parts as part of a larger application process
• Service contract between consumer and providers to govern information interchange
• Support for business services relevant to the consumer, aggregated from back-end services

These requirements can all be encapsulated through abstraction, an absolute requirement for all SOA environments. Architects and analysts have varying names for this requirement, including service virtualization, service facades, and service views. Through the use of an SOA-ready abstraction layer, common infrastructure elements can be shared across all services, resulting in reusable services that are simpler to manage and built for change.