what are the SOA most common techniques?

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

First, read this: http://www.soaspecs.com/ws.php.

Then read this: http://en.wikipedia.org/wiki/Web_service

Ultimately, everything sits squarely on HTTP. That's the core protocol. What you're asking about is at least two different things. The encoding of document (or arguments) in XML, JSON or something else. The semantics of what's transferred: unconstrained or constrained by HTTP.

XMLRPC - http://en.wikipedia.org/wiki/XML-RPC. This evolved into SOAP. The message is in XML. The semantics are a function call. The message includes the method and the arguments.

SOAP - http://en.wikipedia.org/wiki/SOAP. The message is encoded in XML. It is similar to XMLRPC, with more options, more complex XML and formal WSDL descriptions. http://en.wikipedia.org/wiki/Web_Services_Description_Language

If you use JSON instead of XML, there's no good name for it. It's WS or REST with JSON. It's only SOAP if it uses XML.

There are two general kind of architectures. The SOAP-style request where any verb could be defined in the request, vs. REST where there are just four verbs: POST, GET, UPDATE, DELETE and they're the method portion of the HTTP request.

REST - http://en.wikipedia.org/wiki/Representational_State_Transfer. You can use any message encoding with REST. Some folks use XML, some folks use JSON or YAML. You can easily invent other representations beyond XML and JSON/YAML. However, you are constrained to use the four canonical verbs.

Answer 2

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.

Answer 3

if you want to be current with WS standards use WS* stack. -- Jani Syed