Not Just Web Services
Before launching into a discussion of Service Oriented Architectures (SOA), it is important to understand what they are and what they are not. Given the closeness of the terms Service Oriented Architecture and Web Services, it is easy to assume that an SOA is simply made up of a collection of web services. Not only would that be a simplification, it would also not be true.
Web services constitute a number of technologies, which include XML, SOAP, WSDL, and UDDI. These technologies certainly do provide a basis creating web based software solutions that target specific business areas or application integration problems. While these technologies certainly can play an important part in delivering solutions that fall within the SOA realm, describing a set architectural concepts by simply enumerating some number of web based technologies does not adequately describe the nature or purpose of said concepts.
What is SOA then?
SOA is what the name implies, an architecture. An architecture generally includes a set of guiding principles that describe the organization structure of a system, its components, and their relationships to each other. A good architecture also defines how those systems will be "future proofed" or designed to evolve over some period of time. So, effectively, while an architecture does include some details about specific technologies that will get the company from Point A to Point B, those technologies are only a piece of the puzzle. Those technologies will certainly change over time, and not every legacy solution a company has in house will nicely fit into that same technology paradigm. However, all of the systems do need to talk to each other - they all need to understand their communications contract, or interface. By designing around an interface, the underlying technologies can change or evolve, new solutions can be "plugged in", and new solutions can be created from existing functionality.
SOA is a flavor of architecture that is based around the idea of services. Embracing SOA involves giving up previous thought lines around monolithic applications, where product managers or implementers attempt to go it alone, believing that they can do better on there own than with the help of others. SOA based architectures force people to think about the concept of composite applications - applications that are made up of a series of services that may be provided by any number of vendors or (previously) stand alone solutions.
Noting that SOA is an architecture is certainly not earth shattering, but there are a few key concepts that make it different than other architectures with which people may be familiar. The following guidelines for SOA are adapted from material by Thomas Erl, an SOA Architect and author at SOA Systems.
- Services are autonomous. The logic governed by a service resides within an explicit boundary. The service has control within this boundary, and is not dependent on other services for it to execute its governance.
- Service interactions are based on interfaces - they follow a contract, are loosely coupled, and abstract their business logic to the outside world. Services share a formal contract that allows for them to interact. They need not share anything but a collection of published metadata that describes each service and defines the terms of information exchange. Using the formal contracts allows the services to remain loosely coupled. This means that the dependencies between the underlying logic of a service and its consumers are limited to conformance of the service contract. An interface between two services provides the contract that they each must follow; neither service needs to details of the other as long as they agree to the contract. Implicit in this is that the services, or more accurately their interfaces / contracts abstract the underlying logic. The underlying logic, beyond what is expressed in the service contract metadata, is invisible to the outside world. Knowledge of the underlying logic can cause downstream problems when one service changes and the other does not know about the change. Conversely, as long as both services adhere to the contract, neither will suffer adverse effects from changes of the other.
- Services are composable. Services may compose others, allowing logic to be represented at different levels of granularity. This promotes reusability and the creation of service abstraction layers. In part, this is what allows for composite applications in the portal - the ability to create new applications or provide enhanced functionality by leveraging existing services.
- Services are reusable. Regardless of whether immediate reuse opportunities exist, services are designed to support potential reuse.
- Services are stateless. Services should be designed to maximize statelessness even if that means deferring state management elsewhere.
- Services are discoverable. Services should allow their descriptions to be discovered and understood by humans and service requester that may be able to make use of their logic within certain security guidelines. Not every person in the organization should have rights to see or use every service - services can be locked as read only, or discoverable only with the appropriate credentials.
- All functions are defined as services. This includes purely business functions, business transactions composed of lower-level functions, and system service functions, increasing the usefulness of reuse and the ability to compose additional functions and applications.
Why is an SOA important to my company?
The short answer is because it can save the company time and money in terms of efficiency, reuse, maintenance, and testing. The more detailed answer is a little more involved.
Many companies already have hundreds of systems in place throughout the corporation, ranging from enterprise systems maintained within Corporate groups, to systems that are used and maintained within a single business unit or business area. One benefit of a service oriented architecture is that it can be evolved based on existing systems. An SOA does not require throwing away all of the systems a company has and starting over, but it does require thinking about those systems in a different way. A business service can be created from an aggregate of existing components and exposing them as a service, or it can be exposing a piece of existing functionality from a single application by wrapping it in a web service interface. The key point here is to Leverage the existing assets of the corporation.
In some cases this will require review, as the corporation may have multiple systems that fill a role. The result may be that a system fits the bill as a platform from which to advance and evolve, The result could also be that none of the current systems meet the need, but they certainly provide the process and functionality benchmark for moving forward. Once such example is work management systems. The company can make the choice to evaluate those systems and choose one as the standard, or create a new one using the "best of breed" features, or buy one with the best of breed concept in mind - making sure that is best of breed for the corporation, not simply chosen as best of breed or magic quadrant by someone who is not using the software or using it with a different set of requirements in mind.
SOA allows the corporation to view infrastructure as a commodity. Infrastructure development and deployment will become more consistent across all the different enterprise applications. Existing components, newly-developed components, and components purchased from vendors can be consolidated within a well-defined SOA framework. Such an aggregation of components deployed as services on the existing infrastructure results in the underlying infrastructure beginning to be considered more as a commodity element. Groups within the company will be able to deliver functionality more quickly to the customers as the infrastructure becomes more commoditized and the library of services continue to grow. Building and deploying services reusing libraries and common code components, such as logging and error handling services, will reduce the time it takes to get functionality into the hands of IT customers. As those some services are used over and over again, they will continue to be tested and improved, increasing stability and reliability while reducing cost as time goes on. Risk to the organization decreases as reusing existing services reduces the risk of introducing new failures into the process of enhancing or creating new business services. Meanwhile, the learning curve for development decreases, as does the amount of maintenance occurring on similar functionality.
One of the driving forces at many companies is business transformation. Peering into the technical aspect of business transformation allows one to see that this means that the solutions that we provide be centered around how the business works, not around how developers develop. A good service oriented architecture is process centric, not application centric, and helps us meet the goals of the business in a way that allows people to quickly and accurately make decisions based on good business knowledge. Services existing in an SOA can be chained together or composed to create IT enabled process that accurately represent the business processes desired by the company.
Business transformation also involves a continuous effort of business process improvement. An SOA allows a clear representation of process flows and provides a framework in which those services can be quickly adapted to meet the ever changing needs of the business processes without requiring months of changes to monolithic applications.
