Are SOA and web-services synonymous?

by Amir Shevat

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…

Are SOA and web-services really synonymous?


2006-01-09 13:06:41
SOA is the brand for web service promises
I've yet to see a description of SOA that presents it as anything other than a brand for the original promises of web services, ie. loosly coupled services interacting to achieve some larger goal. In that sense, SOA is nothing new. We've been doing it for years now.

As for XML, I don't see how it provides any advantages over YAML or plists if one insists on readability. The one exception may be some of the security related SOAP specs, but those likely only apply to a small subset of people doing web services. At that point it feels as though SOAP is another J2EE stack targetted at solving very difficult problems that a few have while making it painful to solve the simpler problems that many people have.

2006-01-10 06:03:26
Some thoughts
Sorry about being nit picky but SOA actually stands for Service(s) Oriented Architecture and not Software Oriented Architecture. As for the last comment that was made. The point of XML is to provide a implementation neutral method of passing data and SOAP is an implementation neutral way of communicating. HTTP being the most common method of transporting SOAP. Web Services is one avenue of implementing SOA but not the only way of implementing SOA. I agree that the idea of SOA has been around for a while but I think the real treasure of SOA and web services is the ability to integrate software built on different platforms a little more easily than before. Just my two cents.
2006-01-10 06:13:32
Further reading...
Just to let you know...there is ongoing work to create a standard method for serializing XML into a binary format to increase performance...

But we can always just buy bigger boxes and fatter bandwidth, right? ;)

In addition, the WS platform has been built so that transports besides HTTP can (and should?) be used. JMS and IBM's webSphere MQ are mentioned repeteadly as transports in "Web Services Platform Architecture"...

If you've only been exposed to SOA and WS via lectures (buzz), I would highly suggest this book as the next step. It is authored by the creators of the W3C Web Services standards stack, and talks in depth about the technical challenges the Web Services standards are meant to address - basically, the type of content you seem to be interested in.

All of the points you raise are valid, but they're not new. The concerns you express are just some of the many that developers should keep in mind when thinking about using web services and/or SOA.

2006-01-11 01:55:38
Just regarding your point on the sync / async comparison.

FYI, the Inland Revenue here in the UK allow self-assessment tax returns to be filed over the internet. I happened to do this last night. The software I used displays the calls made to the underlying IR server so you can see the way the conversation goes.

First there is one or more submission calls, then there is a series of polling calls which return "Busy" while the IR server is validating your submission, but returns "Successful" once the submission is validated (or presumably an error message if not).

I imagine this is a very busy site, particularly at this time of year around the deadline so I was surprised they used polling when they could have just sent an email like most sites.

So long as the server can very quickly determine the appropriate response to a polling call, it is a valid technique, with the caution that that in itself may require as much development effort as a more simple async method.

2006-01-11 12:52:46
SOA is a puzzle, WS are a piece
Interesting article Amir, and I like your bottom line! (although I tend to disagree on some other parts of your post).
Web services are only a very small part of the SOA puzzle. Web services only matter with SOA at the very basic physical level of your Architecture (the A in SOA). I have explained my point of view at
2006-01-11 17:39:02
SOA is a puzzle, WS are a piece
Thank you for your comments Loek,

I have just read your interesting blog and I think that we share the same point of view. I agree that most web services preferably are asynchronous; I agree that TCP is a much better option then HTTP in most cases and I agree that in some cases XML is not the best answer for providing a service. Finally I agree that SOA and web-services are not synonymous, but I do think that some people see them as such.

Please note that I did not mention binary XML in my blog at all, it was posted as a comment to my blog.

Anyway, all I wanted was to point out some questions without providing a definite answer and to see what other people are saying about this subject, up until now I am happy with the results.


2006-01-13 14:14:32
SOA on an embedded system
We use an SOA on an embedded system. We use a super-light-weight JMS implementation and serialization (but only where we needed it). We'd started with a full-up WS approach, but decided we really didn't need much of it. It works great.