Are SOA and web-services synonymous?

Email.Email weblog link
Blog this.Blog this
Amir Shevat

Amir Shevat
Jan. 09, 2006 10:28 AM

Atom feed for this author. RSS 1.0 feed for this author. RSS 2.0 feed for this author.

Recently, I have attended a few lectures about service-oriented-architecture (SOA). As we all know, there is a big buzz over SOA and most of that buzz ties-up SOA with Web Services (WS). I do not think this coupling is required or even beneficiary for both technologies.

SOA is an architectural paradigm whose goal is to achieve loose coupling among interacting software applications. Applications invoke a series of discrete services in order to perform a certain task. A service is a unit of work done by a service provider to achieve desired end results for a service consumer.

Web services provide a standard means of interoperating between different software applications. When an application calls web-services it actually invokes remote methods on other applications with the use of XML as a communication protocol (usually over an HTTP transport protocol) .

The common conception is that SOA should be implemented using the WS technology. Most of the WS implementations are based on HTTP as a transport protocol. This fact sets a very big limitation when you use WS to implement SOA. HTTP is a request-response protocol that confines the SOA implementation to a client-server type of services. What do we do if we want asynchronous service invocation? What do we do if we want to build an SOA-event-driven application?

WS can, of course, provide asynchronous calls however, doing so is very cumbersome and requires periodical checking for response by the client or, forcing the client to have its own web-service to handle the response. The “periodical checking for response” approach will probably collapse in a real-world/heavy-load scenarios. But the broader question should be: is it really necessary for every service provider and service consumer to have their own HTTP web-server?

And then there is the question of XML.

XML is hardly the most efficient communication protocol. Some people like XML because it is readable and comprehensible by humans. As oppose to binary data, XML is very easy to edit and understand. Those attributes of XML are a big advantage when one uses XML as a way to configure an application. However, this does not necessarily mean that XML is the suitable means to pass information between applications. We would have computers communicate through spoken language if “comprehensible to humans” was our primary concern in choosing a protocol. Often, other issues such as performance are much more critical to the success of the implementation. Other people say that XML is language independent. I do not buy that. We could have thought of an efficient binary protocol that would be language independent and an acceptable standard. XML is definitely not the only way.

My point is that SOA is cool and WS might be one of the ways to provide access and invocation of some services in and SOA environment. But, other services are better implemented with other technologies. Asynchronous services, for instance, might be better implemented by asynchronous messaging (such as JMS). Heavy duty services, where high volume of data need to be passed between the consumer and the producer may use XML as a control channel (session initiation) but other means to pass the actual data.

The bottom line is that we need to choose the right technology to fit the right task and not to go blindly with the crowds. I guess that this is a good advice for life in general…

Amir Shevat is a senior software developer with eight years of experience in computing.