The concept of Service Virtualization has been in use for some time now and is beginning to gain traction as a capability that can improve the ability to prototype new applications and then develop, test and support those applications in the market.
Service Virtualization facilitates a continuous and automated delivery process improving the customer experience significantly. The term ‘API Virtualization’ is now being used more often offering similar benefits, so what exactly is the difference between the two?
Many legacy organizations started off with monolithic applications which ran on character based green screens all connected to the same machine. As the Client/Server model took over, these monolithic applications were broken down into small parts that could potentially be called from a Client application and became known as services. These services could be called in a number of ways:
- Using IBM technologies such as APPC or even LU6.2.
- Using TCP/IP connectivity with proprietary protocols.
- Using middleware like IBM WebSphere MQ, TIBCO or EntireX from Software AG to act as the broker between the client and the server.
- In the more modern era some of these services have been exposed as SOAP or REST based services to be called using TCP/IP.
- And various other technologies.
These services will use languages for data mapping such as COBOL, PL/1, RPG or even assembler to name but a few.
The Genesis of Service Virtualization
Service Virtualization was born out of a frustration in testing with the lack of access to these services due to security concerns, cost, location etc. Service Virtualization takes the semantics used by those services in tandem with the languages that define the payloads and emulates that combined functionality.
To be effective across an Enterprise whether the service is being called by proprietary TCP/IP protocols or over middleware or other custom methods, Service Virtualization in the broad sense must support the easier (e.g. SOAP and REST) and the most difficult (e.g. proprietary TCP/IP) protocols.
The concept of an API goes back many years, however, now the more usual usage of the term generally refers to a way to call a service in the SOA world.
In most cases, this is using REST or SOAP. There are a number of vendors offering API Virtualization to virtualize specifically these limited set of protocols and essentially XML only payloads.
These products do this well and effectively in a very cost effective way essentially due to the fact that the standards ensure a relatively seamless way to emulate the service and processing and management of XML payloads is quite straightforward.
At the same time, it can be limited in its effectiveness in those enterprises which have multiple other legacy languages or call mechanisms for invoking services.
Essentially the choice will come down to whether you simply need to virtualize APIs in which case products from SmartBear and WireMock may be sufficient for your needs.
If you have legacy protocols for calling your services in addition to APIs, you should consider the products from Ostia, IBM, CA, HP and ParaSoft which provide more extensive protocol and language support and also include API virtualization thus satisfying your requirements with one product.
If you enjoyed this blog, please like and share with others using the links below