Recently I answered a question on stackoverflow.com asking can a SOA be designed with REST? I’m cross-posting the answer here.
At a high Level the answer is Yes, however not completely.
SOA requires thinking about the system in terms of
- Services (well-defined business functionality)
- Components (discrete pieces of code and/or data structures)
- Processes (Service orchestrations. Generally using BPEL)
Being able to compose new higher level services or business processes is a basic feature of a good SOA. XML, SOAP based Web Services and related standards are good fit for realizing SOA.
Also SOA has a few accepted principles – http://en.wikipedia.org/wiki/Service-oriented_architecture#Principles
- Standardized service contract – Services adhere to a communications agreement, as defined collectively by one or more service-description documents.
- Service Loose Coupling – Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other.
- Service Abstraction – Beyond descriptions in the service contract, services hide logic from the outside world.
- Service reusability – Logic is divided into services with the intention of promoting reuse.
- Service autonomy – Services have control over the logic they encapsulate.
- Service granularity – A design consideration to provide optimal scope and right granular level of the business functionality in a service operation.
- Service statelessness – Services minimize resource consumption by deferring the management of state information when necessary.
- Service discoverability – Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted.
- Service composability – Services are effective composition participants, regardless of the size and complexity of the composition.
A SOA based architecture is expected to have Service Definition. Since RESTful web services lack a definitive service definition (similar to wsdl), it is difficult for a REST based system to fulfill most of the above principles.
To achieve the same using REST, you’d need to have RESTful Web Services + Orchestration (possible using some lightweight ESB like MuleESB or Camel)
Please also see this resource – From SOA to REST
Adding this part as clarification for below comment –
Orchestration is required to compose processes. That’s what provides the main benefit of SOA.
Say you have a order processing application with operations like
–
- addItem
- addTax
- calculateTotal
- placeOrder
Initially you created a process (using BPEL) which uses these operations in sequence. You have clients who use this Composed Service. After a few months a new client comes who has tax exemption, then instead of writing new service, you could just create a new process skipping the addTax operation. Thus you could achieve faster realization of business functionality just by re-using existing service. In practice there are mutiple such services.
Thus BPEL or similar (ESB or routing) technology is essential for SOA. Without business use, a SOA is not really a SOA.
