If you've been around the enterprise software industry the last few years, no doubt you've heard the term "service oriented architecture" (SOA). If you aren't technical, it's one of those terms that flies right over your head. That's understandable, given that most definitions of SOA are rather dry. For example:
A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations. (OASIS)
Further complicating the topic is a dictionary-sized list of related technical acronyms such as SOAP, XML, CORBA, DCOM, .NET, J2EE, REST, BPEL and WS-CDL. The list goes on…
Allow me to try a more colloquial definition of SOA:
A new and better way to get a bunch of different software programs to work together so people can do things that require information from each of those systems.
We can also simplify the concept through an analogy: think of SOA as the information technology (IT) equivalent of managing a large, diverse workforce. To get stuff done in a big organization, you need to:
- carefully define your goals and what constitutes success;
- draw on the unique talents and knowledge of each individual;
- get people to speak the same language and work together as a team; and,
- measure where things stand and whether success is achieved.
SOA does all that for IT. It catalogs what systems are in place and what they can do (e.g. what data they own). It specifies a common language that they can all use to communicate, even if this common language is not each system's "native tongue." With those components in place, the organization can build new applications or processes that make use of the multi-system integration. Finally, a SOA coordinates and monitors the processes that span these systems.
Keep in mind that SOA is not a specific piece of technology. It's really a strategy or model for how you go about achieving what I described above. Yes, there are many new technologies or standards (like .Net, J2EE, SOAP and XML) that play a critical role in SOA. SOA has also spawned hundreds of new software products that deliver various components of the SOA vision. And yes, there are many big IT companies that promote SOA a lot (IBM, Oracle and SAP come to mind). But SOA itself is an intangible strategy, just like Balanced Scorecard, Six Sigma and Total Quality Management are organizational management strategies.
But integrating software systems is nothing new, you say. True.
What's new about SOA is that it's now much easier to integrate systems. Moreover, SOA goes beyond just passing data back and forth. It actually manages and monitors complex processes that require multiple systems to work together in real-time (i.e., really quickly). It also defines standards for writing the next generation of systems so that the SOA vision is easier to achieve as the IT landscape evolves.
SOA has a lot to do with the World Wide Web. In fact, "web services" is a form of SOA, or arguably, a synonym. It refers to multiple Web applications communicating over the Internet, or local network, to share data and processes. Online travel websites like Kayak or Orbitz are a great example of web service integration. They don't own the reservation data and they don't do the actual booking on their system.
Instead, they offer easy-to-use websites that manage incredibly complex processes behind the scenes by acting as "web service consumers." That is, they pull data and execute transactions from numerous other systems that are owned by airlines, rental car agencies and hotels that are acting as "web services providers." Those behind-the-scenes systems act as web services to the Orbitz or Kayak websites.
Now that we've covered the high-level idea of SOA, let's drill down into some of the specific concepts and terminology you will come across in any discussion of SOA. Our table below is a glossary of sorts for SOA.
|Concept or Term||Description and Analogy|
|Loosely coupled||Loosely coupled refers to the idea that services within an SOA can provide that service to multiple applications, not just one specific application. This is similar to a workforce where employees work with different teams or departments, depending on what needs to get done. They are not restricted to working for one boss or one department.|
|Metadata||Metadata is data that describes all of the services within the IT environment so that programmers or applications know where to go to find a service and how to make a request of that service. It is similar to a really detailed company directory that lists each employee, their skill set, their responsibilities and their contact information.|
|Call||A call is a request from one system to another to perform a service. The system making the request is a service consumer, while the service fulfilling the request is a service provider. This is like one employee calling another employee on the phone and asking for a piece of information or asking for a specific task to be completed.|
|Orchestration||Typically performed by a programmer upfront, orchestration refers to the act of coordinating all of the various services so that they come together to deliver an application. It is like a senior manager that explains the goal, what each employee needs to be doing to achieve that goal and ensures that the project is completed successfully.|
|WSDL||Web Services Description Layer (WSDL) is an emerging metadata standard for describing what each service does. Think of it as a language for describing all of the roles and responsibilities within an organization. While we can use English to describe employee roles in the workplace, computer systems require their own language to describe each service's role.|
|XML||Extensible Markup Language (XML) is the de facto standard for communication between services within an SOA. XML has been adapted or extended for numerous industries and functions. Just like highly specialized employees have their own esoteric, structured variation of English (i.e., medical doctors speaking med-speak), XML is the language of services.|
|SOAP||Simple Object Access Protocol (SOAP) is a protocol for how services communicate. It is difficult, in this plain English guide, to draw distinctions between XML, SOAP, metadata, etc. as they work toward the same goals, and are closely related. Let's just say that while XML is the language of web services, SOAP is like a guide to grammar, punctuation and usage.|
|.Net / J2EE||J2EE and .Net are two widely used, and competing, programming frameworks (programming languages and related technologies) for building applications within an SOA. .NET is Microsoft's framework and J2EE is supported by Microsoft's traditional competitors (e.g. IBM, Oracle, SAP). Both are mature, effective and work together just fine, despite their backgrounds.|
|Encapsulation||Encapsulation refers to a layer of translation on top of older, proprietary components within an enterprise environment. It's as if you have an excellent, highly skilled employee in Tokyo, but she only speaks Japanese. Rather than replace her or teach her English, you hire a translator and start working together right away.|
|Abstraction||Abstraction refers to the SOA ideal of letting each service provider perform its function and produce its output without sharing the gory details with its service consumer. It is similar to employees having an arms-length relationship where they stick to business and get stuff done, rather than talking their co-workers through every detail of their tasks or personal life.|
|Reusability||One of the goals of SOA is to make application development easier and easier over time. Toward that end, you want each service - new or existing - to be reusable in the future. It is similar to seeking to retain your best employees to leverage their skills over and over again on many different projects throughout their careers.|
|Compositability||Compositability means that services can be joined together to create bigger services that perform more sophisticated applications. That combination can then serve as a service itself. This is similar to building a great team of employees where the whole is greater than the sum of the parts. You would be inclined to put that team on new projects again and again.|
|Autonomy||Autonomy means that each service does what it does best in the manner it sees fit. You want to take advantage of the service's output, not dig into how the service accomplished what it did. If you do dig into how each service does what it does, you lose the SOA ideal of simplicity. It's a lot like letting your best employees do what they do best rather than micromanaging them.|
|Optimization||Optimization means that high performing services are better than low-performing services. It's kind of "no duh!" However, since SOA is a model or strategy, it is important to include this concept. It's just like hiring a team; you want to hire the best-of-the-best because they will perform many, many times better than average employees and at only a slightly higher cost.|
|Discoverability||Discoverability means that you make each web services' function and accessibility obvious so that programmers and applications can understand what they do, and use them. It goes back to metadata and WSDL, which is how services are discovered. Again, it's like having a detailed company directory that details each employee, their skills, and contact information.|
|Relevance||Relevance means that a service has to be a useful and meaningful service or no one is going to use it. This is another "no duh" concept, like optimization. However, it's an important part of SOA best practices. Consider a redundant employee, Jan, who is an excellent key punch operator. She may be a great person, but her skill set is no longer useful to the organization.|
Is SOA for Real?
SOA sounds great, right? Yes, when implemented properly the vision of SOA can be realized and provide tremendous value. However, like all things IT, there is nothing easy about executing on the SOA model. It takes a disciplined IT department and substantial investment to make SOA work.
And now a slightly cynical definition of SOA:
A new three-letter acronym to describe incremental improvements to existing software development techniques, allowing systems to perhaps interoperate more effectively. Also used by highly acquisitive software companies to tell an optimistic story about how they'll get their acquired products to work together.
SOA non-believers will often paint this new model as IT dreaming or clever marketing. To some extent they would be right, because SOA has become a popular buzzword tossed around by many software vendors. Moreover, SOA remains in its early stages and there are still concerns about:
- systems running slower because of multiple layers of translation;
- the challenge of getting disparate systems to share the context of their requests; and,
- nascent standards that do not yet provide adequate security and reliability.
There is certainly reason to consider all of these issues. However, SOA is supported by a huge industry filled with developers that want to see its vision realized. Even if SOA is not a magic bullet, there is tremendous value to working toward the SOA vision and achieving just some of its ideals. The model holds great promise and provides a roadmap for moving beyond historical IT integration and development challenges. We like it.