A comprehensive software system in today’s business comprises of many functional units or service components that provide or coordinate services with third party applications over a distributed network. Such services can be like exchanging data, authenticating a customer’s id, doing analysis etc. The framework upon which these independent and self contained units function is called Service Oriented Architecture. This framework enables components to service requests received from each other based on protocols that are independent of human intervention, programming language, technology, device, vendor or network. For example, services written in different languages and platforms (C++ on .NET and Java on Java EE) can easily interact with each other in SOA. This has given a new lease of life to legacy systems like COBOL run mainframes by turning them into software services. It is the presence of SOA that enables disparate applications in software to ‘cooperate’ with each other in the form of services. This exchange of services gives rise to the functionality of a software system.
The present day paradigms of mashups, SaaS, and cloud computing owe their existence and development to Service Oriented Architecture. Hence, like APIs or individual units of a software system, individual services offered by SOA are needed to be tested as part of SOA testing to reduce batch size, achieve overall functional accuracy, and reduce redundancies in a system. Continuously Delivering SOA offers faster and reliable software development at a lesser cost by automatically building, testing and deploying services. As the process is independent of human intervention, the services get integrated into production without any actual business decision taken in that regard.
Challenges of SOA Testing
- Individual components or dependencies are inter dependent, distributed on different platforms, and might not be available under the same roof or time zone.
- Third party dependencies providing services may prove to be a challenge in terms of cost, location and availability.
- Services existing on different platforms might contain security challenges.
- Entire suite of business functionalities might not generate desired services.
- Services within legacy mainframe systems might not function properly.
As various components of the architecture – mainframe systems, database systems, or services, given their distributed occurrence across locations, time zones and owners are not always available for testing at the same time by parallel testing teams – the paradigm of Service Virtualization comes into play. According to this paradigm, the behaviour of external dependencies is simulated to create a test environment whereby service requests and their responses can be gauged and challenges addressed.
Read More ..