At a high level, the concept of Service Oriented Architecture (SOA) is fairly straight forward. This is to say that most people would agree on the concepts and principles behind it. However, as you dive deeper into the detailed aspects of delivering a system based on SOA, it can begin to mean different things to different people. Understanding exactly what SOA is, is not made any easier by major players in the software industry like Microsoft, Sun, IBM, Oracle, and more who tend to define or bend the definition of SOA in a way that aligns the principles of SOA with the implementation details of their platform technologies, development tools, and methodologies. Try entering “SOA” in your favorite search engine today and you’ll know exactly what I’m talking about. In this article, let’s take a look at concepts of SOA, examine some of the business benefits, and attempt to come up with an “elevator speech” definition for SOA.
SOA in a Nutshell
SOA is basically an architectural style for building software systems based on discreet but interacting components called services. Each of these services delivers on some set of specific business functions. The key with SOA is breaking up a large monolithic software system into discreet services that can be presented to or assembled for the user in different ways to provide a high degree of functionality and flexibility.
Services – The Key to SOA
Breaking up the functions of a software system into a set of services allows the business to plug in new services or upgrade existing services in a more granular fashion in order to address new business requirements. Existing services can be consumed by different business channels, therefore, leveraging existing infrastructure and development investments. Adding new functionality required by a growing business is a matter of adding additional services rather than rebuilding an entire system. Modularizing a software system into loosely coupled discreet services is a good thing since it allows us to change the software more easily and respond better to rapidly changing business needs. Let’s take a closer look at real world business benefits of SOA.
As an example, consider a typical internet store-front system. The shopper is presented with a catalog of items and a shopping cart that the shopper can move items in an out of, and eventually the system accepts an order. The items presented in the store are ever changing. Marketing people are likely to want to change the presentation of items, content of item descriptions, and layouts frequently. Even the whole shopping metaphor may change from a shopping cart to scrollable item list on a sidebar. Marketing may want to experiment with different fonts, colors, and screen layouts and use various presentation technologies, including Ajax and a myriad of other options. But none of this has anything to do with the core business functions encapsulated by the services. The services that acquire catalog data and submit orders remain unchanged despite all the changes to the presentation of products. This underscores the importance of separation of the underlying business process of processing orders from the never ending changes of presentation.
Beyond constant change with presentation, business processes, change as well. Offering new types of products or reaching new markets may require adding additional business processes such as currency exchange, age verification, etc. Meeting the challenge of adding new functionality is more of a matter of adding services in SOA than needing to change major parts of the system. The bottom line is that the services in SOA do not change that often, but the pathways through these services and when and where they are used, do.
SOA is more than just defining and creating services. What separates SOA from other software architectures of the past is the way in which services are discovered, understood, and interacted with.
Contracts – Getting to Know Your Services
Beyond defining the discreet services that are capable of working together to solve business problems, establish a contract for each service. A contract states what a service will do for you, information about what is required to use the service, and the rules or policies around security, etc for using the service. The consumer of the service needs to understand the contract in order to know how to use a given service.
Messages – Using Services
A message is basically a unit of communication between the service and the consumer of a service. Messages may take different forms like SOAP, HTTP GET, SMTP or more. Regardless of the protocol, messages are basically made up of header and a body. The header provides information about routing whereas the body contains the actual message data.
End Points – Finding Services
An Endpoint is basically an address where the service lives. In the case of web services it’s a URI (Uniform Resource Identifier).
On The Elevator
Software architectures are basically defined in terms of their components, attributes, relationships within, and the rules that govern them. So we can define SOA as a guide for building systems based on autonomous components labeled as services. Each service is accessed at a known endpoint and exposes its processes and behaviors via contracts which take the form of messages.
The business benefits of SOA can be summed up as providing a higher degree of agility and allowing the business to respond quickly to ever changing requirements of the marketplace while leveraging investments in applications and software infrastructure.