Service Virtualization

Will I loose the core concept of Service Virtualization if I use the DevTest DB to store real-time data for my virtual service?

Eg: I have 2 services, a PUT and a GET. What if I store and map the data coming from the PUT in the DB and use that data in the GET? Am I creating a real service? Am I losing the whole purpose of SV?

Please provide your comments.

Hi,

Some would argue yes. However from a developers point of view, I would prefer to say that you are using the product in a new way. I have argued that is easier to develop a virtual service if you have knowledge of the requests and the responses. As opposed to having a spare server, installed the target environment, coded a responder and deployed it.
So by way of an example: I am a UI developer, I know the requests I am making and I know the responses I am expecting. It is easy to generate a virtual service based off of that information. The alternative is to learn how to write, test, deploy and maintain a responder. Do I want to know how Apache/Tomcat/WebSphere/WebLogic work - probably not - or just create a simple virtual service to give a response.

So whilst your application of DevTest is not a standard use case - I commend you.
Yes you have created a real service - but you let DevTest write, build and deploy it for you - and you didn't have to write any code - except maybe to access the database.

Bravo

^^ +1 AndrewHaigh

BJG, based on your description, I would say you are not violating the principles of SV. Rather, I submit that you are implementing the concept of a stateful virtual service without using the OOTB stateful model pattern provided by the VSE.

The reality is that our stateful pattern does not always meet the requirements necessary to manage state when dealing with a real customer system-under-test. For example, implementing services that must respond to the concept of transactions within transactions with no single identifier to tie the txns together.  When this occurs, many of us use Shared or Persistent Model Maps, others find interesting ways to delegate behavior across several virtual services, and in your case, you chose to persist and retrieve data (which, by the way, is essentially the same as using our Persistent model map feature).

The only caution I would offer is that by adding your own custom tables into the DevTest DB schema, you have to pay closer attention to product version upgrades, manage the DDL, potentially clean up the table accordingly, and so on. 

Check out the scripting guide @ DevTest 8.0 - Scripting Guide - V1.1.pdf  and refer to pages 23 - 26. There is discussion of the Persistent Model Map API.  If you have no requirement to manually manipulate or maintain the data in the tables, a Persistent Model Map implementation may provide you a path to alleviate product migration issues.  

Thanks J_NeSmith and AndrewHaigh for your insights. I would have used Persistent Model Map if that would have solved my requirement. Here the consumer system testers want the data to persists and also get updated as and when they push the new data. I thought that my approach of keeping the data in the DB will be more efficient than using the Persistent Model Map. But I've made sure that I don't write any transformation logic. I only do the static mapping in the response present in the VSI.

Also, I've some plans around the maintenance of the associated DB. Currently, I'm using the derbyDB, but may consider upgrading it to an enterprise DB if need arises.