Many sources make it quite clear that the use of web services (WS) does not automatically lead to a Services Oriented Architecture (SOA) and that web services are merely an enabling technology for SOA. Given however that today�s SOA implementations usually use WS, what are the advantages, if any, in your opinion, of keeping the architecture (SOA) ignorant of the implementing technology (WS) (besides keeping the architecture separate from implementation)? [ May 29, 2007: Message edited by: Peer Reynders ]
It is true that SOA doesn't require the use of Web services. Nor, does the use of Web services imply that you have implemented SOA. SOA, as an abstract paradigm, is a architectural philosophy of distributed computing that prescribes the construction of applications based on message passing among loosely-coupled services. The messages do not need to be XML. The services do not need to be HTTP endpoints.
Likewise, it is possible to use Web services to build tightly-coupled RPC style systems that do not adhere to SOA.
Practically speaking, however, I think that SOA and Web services are difficult to separate. I think it is difficult to build systems according to SOA principles without Web services standards because the Web services standards provide the language - i.e., XML and WSDL - needed for documenting the architecture.
For example, Chapter 4 of my book describes the importance of standard message definitions (e.g., a standard purchase order) in a SOA. Well, in order to create a repository of standard message definitions, you need a standard language - i.e., XML Schema - for specifying the definitions.
At the implementation level, your architecture may translate XML into something else (e.g., see MTOM) for performance reasons. But at the architecture level, you need a common language so that applications can talk to each other. XML is the most important component of that common language. And XML Schema is required in order to write specifications about XML messages. The other important building block is WSDL - it is required to document interface definitions.
So, to answer your question ... It is possible to keep SOA ignorant of WS, but then you have to invent some language other then XML, XML Schema, and WSDL to document your services. And then you have to provide a way to bind that documentation that you have invented to the underlying application implementation languages (e.g., Java, C#, PHP, etc.). All that work is avoided if you just start out by documenting your SOA using the existing Web services standards.