If you are working in the area of software development, you’ve probably run into a situation where one layer of service was ready but another wasn’t, either due to more time taken for higher complexity of implementation or something else. Traditionally, in such cases the layer of service – which was already built – would wait on this complex layer to be ready, integrate with it, and system integration testing would begin thereafter. But with growing pace, scalability and competition to deliver products with a much quicker time to market, industries are experiencing a gradual shift to find an alternative solution to simply waiting on everything to be ready before moving to the testing phase. This is where the concept of service virtualization comes in. If something is not ready, have it virtualized, connect all pieces together, and proceed with unit and integration testing. This has two advantages that improve the speed and quality of delivery by several magnitude:
- Development of an unavailable service layer can proceed as is
- A lot of code bugs can be caught and fixed upfront instead of waiting until true system integration testing can take place, which would be a great bonus for everyone
Service virtualization is gaining widespread popularity for a few other reasons as well. It supports test-driven development, thereby reducing the total development-testing and code fix efforts by several days to weeks, based on the complexity of implementation and use-case. Virtualized service architecture can also be used for training purpose, load testing of some sort, as well as simulation of the product. With such advantages, I think it is bound to be extremely successful with clients.
As far as virtualizing web-service component is concerned, there are two fundamental ways of doing it:
- Traffic-monitoring and recording:
In this approach, a proxy is enabled to simply listen over the web-service traffic. Based on the request-response captured, it can create stubs and hence virtual service can be built out of it. The longer the total time period of recording traffic, the more service scenarios are captured and hence stubbed. However, we can also manually add/update the scenarios in it. - Build virtual services from WSDL:
In this approach, you use the service specification/WSDL to create virtual service stubs. This does not require any proxy or listening, and hence it could be more manual process.
Both come with their own advantages and disadvantages. A lot of clients are already achieving these benefits by leveraging service virtualizations. These clients belong to all the domains, ranging from healthcare to telecommunications, financial and energy sectors, and even software giants. CVS, United Healthcare, Anthem BCBS, FedEx, Apple, AT&T, JC Penny, Allstate Insurance, JP Morgan Chase, and the US Army are some of the common names of organizations who already have a well set up infrastructure for service virtualization in addition to a lot of Fortune 500 clients.
There are lots of software vendors who have invested in this area and are reaping benefits from it:
• CA LISA is very popular tool for service virtualization
• IBM has recently taken over Green Hat and named is Rational Integration Tester, which is also an excellent candidate for it
• ParaSoft offer great service virtualization capabilities
• There are a bunch of upcoming and open-sourced technologies also available for the same
How is your organization leveraging service virtualization?
