Nowadays, service virtualization technology is widely used for development and testing of applications (such as service oriented architecture based applications) across various service based enterprise industries. Service virtualization is a method of developing virtual application services (virtual services or virtual service packages) by emulating behavior, data and performance of real application services of various enterprise systems. Using virtual services, developers and testers (also referred as user) can proceed with developing and testing without accessing actual components of the real application services.
Conventionally, various software virtualization tools are available which perform service virtualization using various scripting languages such as Java script, .Net script, European Computer Manufacturers Association (ECMA) script etc. or using Application Programming Interface (API) based capability.
The support for abovementioned scripting languages is in-built in the software virtualization tools and is specific to each tool. Typically, in order to mimic accurate behavior of real application service components, service virtualization involves writing complex business logic for a virtual service package into a software virtualization tool using scripting mechanism specific to that tool for generating service responses.
There are, however, several drawbacks associated with the conventional in-built support provided by the software virtualization tools. Once business logic corresponding to the virtual service package is built into the software virtualization tool, the virtual service package cannot be reused with other software virtualization tools as each software virtualization tool has a specific scripting and execution mechanism. Further, various software virtualization tools specific constraints act as a deterrent for reusability of the virtual service package. For using the virtual service package with the other software virtualization tools, the virtual service package needs to be migrated to other software virtualization tools, which entails huge computational overhead, cost and time. Yet further, scripting support provided in the software virtualization tools is not capable of delivering expected performance, execution patterns, program-control over service behavior and handling anticipated changes in the virtual service packages in view of business dynamics.
Furthermore, during application testing or application development activities using virtual service packages via the software virtualization tool, recorded responses or generated responses are provided back to querying clients. For instance, the responses are generated by users of the software virtualization tools by manipulating data using different data-sets, business rules or conditions and service behavior using respective in-built scripting mechanisms. Using such ad-hoc generated or recorded responses may not achieve the desired testing or development results.
Furthermore, conventional methods for integrating external virtual service packages with a software virtualization tool are via scripting, which again will be different for different tools. As such, once the external virtual service packages are built using a specific software virtualization tool, it cannot be reused with other software tools. In order to integrate or offer the same virtual service package with other software virtualization tools, the same business logic needs to be completely rewritten as per the software virtualization tools' standards. This involves extensive redesigning, development and maintenance overheads to comply with business dynamics and to satisfy business requirements.
In light of the above drawbacks, there is a need for a method and system to provide virtual service packages that are reusable across all service virtualization tools. There is a need for a service virtualization mechanism that is independent of service virtualization tool specific methodologies. Also, there is a need for integration and execution of virtual service packages with adequate reusability, and yet satisfying all performance and business requirements of virtual service packages. Additionally, there is a need for a service virtualization mechanism via which external virtual service packages are identified, invoked as well as executed, despite the external virtual service package developer's lack of knowledge of service virtualization tools used by the service virtualization mechanism.