When choosing the architectural style that suits your business requirements, there are points aplenty that you have to consider. The following table compares the different architectural styles:
|
Attribute |
Object Oriented |
Resource Oriented |
Service Oriented |
|---|---|---|---|
|
Granularity |
Object instances |
Resource instances |
Service instances |
|
Support for caching responses |
No |
Yes |
No |
|
Payload |
Yes, it is usually middleware specific |
No, you have nothing that is linked to a particular address or URL |
Yes, the WSDL schema |
|
Addressing or request routing |
Unique object instance |
Unique address of a particular resource |
Endpoint address of the service |
|
Coupling between server and client |
Tight coupling due to object serialization and early binding to interfaces |
Loose coupling due to late binding to resource data |
Loose coupling due to late binding to service interfaces |
An OOA is best suited when the coupling or cohesion between the server and the client components is tight and is therefore best suited for closed systems.
Service Oriented Architectures involve loose coupling amongst the client and the server components due to late binding to a service interface. These systems are flexible, and tend to scale well because of their stateless nature. These architectures are best suited for shared systems that can work across organization boundaries. The following figure shows the comparison between Service Oriented and Object Oriented architectures:
Comparison between SOA and OOA
Resource-oriented systems involve loose coupling between the server and the client components, and they are best suited in scenarios where you need late binding and cache-ability of resource data. These systems are scalable due to their stateless nature.
In essence, ROA is an architectural paradigm that thrives on four basic concepts: resources, the names of the resources, the representations of the resources, and the links between the resources. It is also based on four distinct properties: addressability, statelessness, connectedness, and a uniform interface.
Choosing the right architectural style entirely depends on your business requirements. In essence, you can design a web service application that can use a combination of architectural styles with a resource-oriented approach for simple data reads and a service-oriented approach for complex data operations.