Question

I’m studiyng the SOA concept and found out the techniques (should i call it like that?) SOAP and REST (only these ones). I want to know if there are any other techniques (?) that coexist in this context and what do they represent. are they better in something? does many people use them? etc. thanks (:

Answer 1

Its important to separate SOA the architecture from SOAP , REST and other implementations of the architecture.

You can implement a SOA architecture on top of any technoligy that supports request and response via messages.

The core characteristic of a SOA architecture are:-

• Clients send simple request messages.
• Server repsponds with single reply messages.
• Service interfaces are well defined and “advertised” to clients. i.e. CLients can query the server on what services are suppoted and what the interface for these services are.
• No replication of data and no local storage. If a client wants to know about a Widget then it queries the Widget service, the client does not retain any of the Widget data. Likewise if a client wants to update a Widget’s details it sends an update request to the Widget service.
• Synchronous, Asynchronous and Batch interfaces are all acceptable.

The key advantages of this as an architecture are:-

• The only contact between a server and its clients is the “interface”. The client has and needs absolutly no knowlege of the servers implementation, likewise the server does not care how a client is implemented.
• The data is owned and managed by the Service and only the service. This eliminates synchroisation, replication problems, and reduces to almost zero the possibility of double updates.
• The absolute simplicity of the resulting architecture allows for great flexibility.
• The absolute simplicity of the resulting architecture makes for very reliable systems.

However as you quite rightly concluded in the real world mostly SOAP and REST are used. When people say SOAP they are usually refering to the WS-* series of standards and protocols –>WSDL (Web Service Definition Language), WSM (Web Service Messaging) , WS-Security etc. etc. which use SOAP as the transport mechanism.

Whereas REST has the virtue of simplicity, and, the WS* is highly complex and more difficult to implement I would recommend the WS* approach for any reasonably large system. The WS* standards support not only simple request/response but also asynchronous messages and transports other than http (JMS, files etc), and, more importantly the WS security standard is well though out and supports secure business to buisness communication.