Is your business based on making calls to clients and suppliers, and you can't afford to pay the extreme amounts of phone bill? You should consider getting a broadband phone…
Advantages and Disadvantages of Service-oriented Architecture (SOA)
SOA is an architectural approach that aims at developing modular applications consisting of independent services, which fulfill a specific task and communicate with each other in concordance. Techspirited discusses the advantages and disadvantages of implementing a service-oriented architecture.
SOAs can be implemented via web services, but web services are not necessarily required to implement SOA.
Service-oriented programming is the latest technological evolution that deals with the drawbacks of objected-oriented programming. Though OOP simplified code reusability and management, it did not permit two or more applications to communicate with each other, particularly when they have been written using different programming languages. For instance, an accounting module in .NET will not be able to call functions inside classes of an inventory module written in Java. This led to the development of service-oriented architecture, where services became the key components rather than the objects.
What is SOA?
Service-oriented architecture is a style of architecture based on service. A service is a well-defined and self-contained functionality. In this architecture, different services communicate with each other to perform some activity. These services are loosely-coupled i.e., a service need not know the technical details of another service that it is interacting with. Basically, SOA consists of a service consumer and a service provider. The former requests for some service while the latter executes the service and returns the result for the request. While communicating, the service provider and the consumer both adhere to a pre-defined protocol.
While there are many pros and cons of using service-oriented architecture, we have listed out a few important ones for your quick reference.
❑ Service Reusability
In SOA, an application is built by assembling small, self-contained, and loosely coupled pieces of functionality. Therefore, the services can be reused in multiple applications independent of their interactions with other services.
❑ Easy Maintainability
Since a service is an independent entity, it can be easily updated or maintained without having to worry about other services. Large, complex applications can thus be managed easily.
❑ Greater Reliability
SOA-based applications are more reliable since small, independent services are easier to test and debug as compared to massive chunks of code.
❑ Location Independence
The services are usually published to a directory where consumers can look them up. This approach allows a service to change its location at any time. However, the consumers are always able to locate their requested service through the directory look up.
❑ Improved Scalability and Availability
Multiple instances of a single service can run on different servers at the same time. This increases scalability and availability of the service.
❑ Improved Software Quality
Since services can be reused, there is no scope for redundant functionality. This helps reduce errors due to inconsistent data, and thereby improves the quality of code.
❑ Platform Independence
SOA facilitates the development of a complex product by integrating different products from different vendors independent of the platform and technology.
❑ Increased Productivity
Developers can reuse existing legacy applications and build additional functionality without having to develop the entire thing from scratch. This increases the developers’ productivity, and at the same time, substantially reduces the cost of developing an application.
❑ Increased Overhead
Every time a service interacts with another service, complete validation of every input parameter takes place. This increases the response time and machine load, and thereby reduces the overall performance.
❑ Complex Service Management
The service needs to ensure that messages have been delivered in a timely manner. But as services keep exchanging messages to perform tasks, the number of these messages can go into millions even for a single application. This poses a big challenge to manage such a huge population of services.
❑ High Investment Cost
Implementation of SOA requires a large upfront investment by means of technology, development, and human resource.
SOA is not recommended for the following type of applications.
- Homogenous: Implementing SOA for applications that use the technologies of a single vendor will not be cost-effective. For example, if an application is built in Java, then it would be better to use methods of Java rather than using HTTP for inter-component communications.
- GUI-Based: SOA would not be suitable for applications with GUI functionality, e.g. a map manipulation application. Such applications require heavy data exchange, which in turn would increase the complexity of the application if SOA is used.
- Real-time: SOA is not desirable to be used with strictly-enforced response times since the services communicate asynchronously.
- Stand-alone: It would be futile to invest in SOA for stand-alone non-distributed applications, which do not require request and response-based calls.
The architecture for any software application needs to be selected wisely since it involves factors like investment cost and human effort. Once you are able to understand when and when not to apply the service-oriented architecture, you can make the best use of it in your software development process.