Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

SOA without Web services

Thomas Erl discusses how Web services provide us with an implementation option, and why you do not need Web services to build service-oriented architecture.

In SOA we publish our functions in the form of Web services. It seems quite feasible if we are dealing with the general purpose service that many people on the Internet use it, but is it feasible for an application deployed in a corporation with limited people to serve and with a more strict security policy?

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).

Dig Deeper on Topics Archive

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

Hi Thomas,

So, how can one design SOA-compliant system without Web services?

My work is focused on using SIP as a platform for services. It seems that SIP architecture support some SOA tenets.

Unfortunately, I am not an SOA expert and cannot definitely state this.

What do you think about it?