SOA without Web services

Digg This!     StumbleUpon     Del.icio.us

RELATED CONTENT Service-oriented architecture: Technology and design Web service statelessness Private sector SOA Keys to an SOA implementation Validation abstraction A brief history of SOA Implementing ESBs The evolution of SOA Obstacles to SOA transition Aligning SOA Examples of SOA SOA implementations New SOA products for November 2009 SOA implementation evolves from open source to Oracle SOA suite U.S. Coast Guard adopts SOA and ESB to better track ships at sea SOA Implementation: Should top down meet bottom up? ESB watered down by EAI, but distinction remains On the road to SOA – Part 1, Boubez on early insights On the road to SOA – Part 2, Governance is fundamental Sparx releases new SoaML profile for Enterprise Architect 7.5 SOA implementation: It's the increments, stupid Bury SOA inside a larger architectural vision SOA implementations Research

RELATED GLOSSARY TERMS Terms from Whatis.com − the technology online dictionary Service Integration Maturity Model  (SearchSOA.com)

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary

While Web services provide us with an implementation option for services being delivered as part of an SOA initiative, you do not, in fact, need Web services to build SOA. This is a common misperception that has led to much disappointment. Organizations assume that a service-oriented solution is simply qualified as one that incorporates Web services. They then move ahead with the Web services-based solution while expecting the well-publicized benefits of SOA to materialize. When they don't, the project usually fails and blame is directed at the vendors, the project team, or SOA itself.

I won't get into how SOA is a distinct architectural model associated with the service-orientation design paradigm because you can read up about all of this at http://www.whatissoa.com. However, to get back to your question, even if you do build your services as Web services, you certainly can use them within your enterprise. Many companies have standardized on the use of Web services to represent key endpoints to applications, legacy systems, and newly created solutions. The result is a proliferation of messaging based communication and Web servers become a standard part of solution hosting environments.

It really helps to familiarize yourself with the modern Web-based technologies. Once you do, you'll soon discover that their use is not limited to external, Internet-based data exchange. Having said that, though, you may still run into situations where certain constraints and requirements demand that you use regular components instead. Your example of a security policy is a good one, because security requirements (especially for agnostic services that need to accommodate multiple different types of consumer programs) are a relatively common reason that services are not deployed as Web services. This is particularly true within vendor-diverse environments where different proprietary platforms support different subsets of the WS-Security framework (or, the same features are supported but differently implemented).