7 Myths of Service-Oriented Architecture
InfoManagement Direct, March 12, 2009
Service-oriented architecture has proven to be a boon in the computing world. At its core, SOA provides enterprise patterns for systems development and integration where legacy systems are viewed as discrete business capabilities and packaged as standards-based services interfaces. SOA also typically describes an IT infrastructure that allows different applications to exchange data with one another as they participate within business processes.
Over the past few years, SOA has grown almost exponentially in popularity, becoming one way for companies to knit together applications and processes in a flexible, reusable and cost-effective way. SOA separates functions into distinct units, or services, which developers make accessible to users over a network, ideally allowing them to combine and reuse them in the creation of business applications. These services communicate with each other by passing data from one service to another or by coordinating an activity between two or more services.
However, like virtually any technology, business process or computing approach, there are misconceptions surrounding it - what it is, how it is used, its benefits and risks and who should be using it.
Advertisement
Myth #1: SOA and Web Services are the Same
To begin with, there is rampant misunderstanding around what SOA actually is. Some people will claim that SOA is simply the same as Web services and even use the terms interchangeably. The truth is, Web services, such as SOAP over HTTP, represent a standard means of defining an interface and fit the architectural pattern that SOA defines. The importance of these standards cannot be overstated, as they are instrumental in allowing systems of different types to communicate with each other without the need for a proprietary protocol.
Conversely, SOAs are based on underlying, guiding architectural principles, combined with so-called “best practices,” which ultimately allow the functionality of a Web service application to be asserted in an open fashion. SOAs and Web services are not interchangeable. Certainly, Web services can be used to build SOAs; in fact, they are the de facto standard for deploying SOA. Yet, SOAs do not necessarily depend on Web services standards, since SOA can also be implemented using CORBA, JMS, MQ and other interface/messaging standards alone or in parallel. The reality is that Web services can be viewed more as an interaction pattern within an SOA, typically describing an interaction between clients and a server over HTTP as opposed to SOA itself.
Ultimately, an SOA can be Web services-based or even based on SMTP email as an interface standard. However, by defining Web services as being equivalent to SOA you may lose visibility into many other types of SOA-based interfaces and capabilities that allow the kind of loosely coupled, autonomous, reusable components that define a real SOA.
Myth #2: You Can “Buy” SOA
One of the primary myths regarding SOA is the idea that it’s something that can be purchased, that SOA is an actual product that can be acquired for a business. Many organizations attempt to buy SOA in the form of relatively expensive infrastructure components, with products stacked against specific class capabilities such as directory, discovery or messaging. After acquiring these items they will declare that they now have SOA. However, this is far from the case. The true benefit is not the infrastructure that the SOA rests on but on the services that can be elicited from the infrastructure. Too many companies mistakenly focus their attention on creating a technology infrastructure and consider that a successful SOA implementation, rather than understanding that creating a platform for the delivery of valuable and functional services is the first step, needing to be accomplished in parallel with the identification, definition, design and development of the services that will ride on the SOA infrastructure.
While it’s true that you may eventually need to buy a repository to manage the services, a registry for other applications to find them and a mechanism for service consumers and providers to exchange business information, you may well be able to get started on SOA and achieve strong business benefits without buying anything new.
Myth #3: SOA Reuse Is Simple
While the reuse of software can be achieved on a small scale, it is exceedingly difficult to make it happen on the enterprise level - in that regard, SOA is no different. It can be extremely counterproductive to “force” the reuse issue, and trying to create services for each individual application or repository in an enterprise can lead to serious issues around maintenance and compatibility.
Ultimately, it’s best not to attempt to design only for reusability within the SOA development process. The optimal choice is to let SOA-style services suggest themselves based on requirements at the enterprise level. Given that point, it’s important to note that after you’ve modified an interface a couple of times to facilitate reuse, the “service” starts to present itself.
Myth #4: Acquiring a SOA Is Expensive
Many people are under the impression that launching an SOA is a costly endeavor. No doubt, there is a sizeable capital outlay necessary to create an SOA, but often that initial outlay is focused only on the infrastructure components identified previously. Many organizations believe that to create a SOA, you need a complete SOA stack made up of directory services, discovery services, message services and media mediation services, along with a portal for visualization and display. But you can achieve many of the core benefits of SOA without purchasing many of these components. You can achieve many of the benefits of SOA (standards-based services interfaces supporting information exchange) without any of the traditional core SOA infrastructure components.
As organizations’ SOA mature and begin requiring infrastructure components to expand their capabilities, there are many low or no-cost options available. Today, in fact, there are numerous open source technologies that provide the platform capabilities for an efficient and scalable SOA. And for the most part, these open source technologies are robust enough to power an SOA for an entire enterprise.
Myth #5: SOA Solves All Integration Problems
Page 1 of 2.
