What is the difference between SOA and ROA

Question

As i know SOA(Service Oriented Architecture) is based on collections of discrete software modules, known as services. These services can exchange information with any other service within the reach of the network without human interaction. SOA uses SOAP or REST protocol to transfer XML or JSON document between various services.

But i'm confused with ROA(Resource Oriented Architecture) and about what is the difference between the two architectures.

Any help will be appreciated, rectify me if i'm wrong.

Answer 1

As the terms imply a Service Oriented Architecture is oriented at services, and a Resource Oriented Architecture is oriented at resources. In general differences between two things A and B are often best explained by defining the essence of A and B. So it comes down to the question, what is a 'service', and what is a 'resource'?

I'll leave that mostly to the reader, as most developers probably have an idea of what either is. Although it's actually not that easy, as one thing could be seen both as a service, and as a resource (similar to the classic Wave-Particle duality of light in physics). For instance, Flickr is a service that provides you with photo's, but can also be seen as a resource for photos. But basically a resource is more static data (like a photo) and a service is more processing (e.g. delivering a photo, or resizing a photo so they can show a thumbnail of one).

I understand the difference best by looking at the way an application implement its 'functionality':

• An application built with a Service Oriented Architecture is more a 'Facade', e.g. it combines or composes its outgoing functionality based on functionality that is in the services it uses 'behind the screens' (possibly over the network). E.g. its core processing consists of calling external services, supplying them with parameters, and combining the results with possibly some extra processing or algorithms for the user.
• An application built with a Resource Oriented Architecture does more of its processing internally (e.g. as opposed to calling external components) but uses external resources as input. E.g. its core processing consists of retrieving static resources and then doing more calculating internally.

Answer 2

I'll rectify first:)

For the purpose of this answer let's just say that REST is a way of organizing resources and the operations you perform on them.

SOA uses SOAP or REST protocol to transfer XML or JSON document between various services.

Absolutely not. REST is not a protocol. SOAP is a protocol, that's true. It is frequently used in SOA architectures, particularly for the implementation of SOAP over HTTP or SOAP over JMS. However, SOA does not imply SOAP. You could use any other protocol. Same applies to XML and JSON. You could use just any other language or dialect.

Now the explanation. SOA is service oriented architecture. Therefore the whole system is made up of services that typically perform some operations. The architecture is based on this. Imagine a cloud of servers where each one holds at least one service, for instance WeatherPredictor, ForexCalculator, etc.

Opposed to this you have the resource oriented architecture, ROA, where the system is made up of resources. Imagine a cloud of servers where each one represents one or more resources, for instance Weather, Euro, Dollar, ...

ROA is typically used in big, open systems, because of the advantages it brings. In ROA architectures you would typically find RESTfull services. RESTfull services are nowadays typically implemented with just JSON over HTTP, or XML over HTTP.

SOA is used a bit everywhere. In SOA you commonly find the SOAP over HTTP, SOAP over JMS, etc.

But some day you may encounter a RESTfull web service that for some weird reason uses SOAP (perhaps the developers needed to embed the message in the SOAP envelope for some obscure reason). I think you won't find this example in real life, but just to show you that SOA or ROA do not imply the protocol to be used, in this case SOAP.

Hope this helps.