This is the third post in our six part series on Service Virtualization in Enterprise Application Development. The series covers how service virtualization complements hardware virtualization with the ability to reduce cost and increase business agility across the entire software lifecycle.
The complete white paper on Service Virtualization in Enterprise Application Development can be downloaded from itko.com.
In this post, we move from hardware virtualization approaches to the service virtualization concept. Taking the concept of virtualization all the way into the service interactions and behaviors of my interconnected systems opens up new possibilities. When assets make the migration from the real world into the virtual world, they lose their constraints. I can control their behavior, I can control their capacity, their access, and I can constrain them in the ways that I want – not the ways that the real world imposes upon me. This is exactly the technique this paper covers. See an example below.
Let’s look at an example. First, the current physical environment is shown below. This presents several challenges.
Access to a mainframe: The trouble here is that because I’m not the only team in the environment, there are dozens of other project teams; therefore I have very infrequent access to the mainframe.
Access to a database: Another other team owns a database that we access. This database already exists; we even have access to it in a development lab, but we need new stored procedures in that database schema. It will take some 3 or 4 months of negotiating and design work to produce those stored procedures.
Access to the web service: There is a legacy system already deployed, and we’ve decided that as an architectural mandate, we are going to use web services to get at the legacy functionality; which is great — except that the web service doesn’t actually exist yet – we’re still shopping the contract so access is months away.
All of the above are very real world constraints — these are nothing that we haven’t heard dozens of times from our customers. So let’s see what service virtualization can do to remove these constraints. We will describe the diagram below form the bottom up.
For mainframe access, build a model of the behavior and then host it as a virtual service in a virtual service environment. For database access, construct a model from the database and make changes as needed within minutes. For web access, construct a virtual service from a WSDL, from SOAP documents, from XML samples: whatever you can give the Virtualization team. Now I will go into these concepts in more detail in the next three posts. In the next post, I will cover reference architectures, starting with Stage One, in which no virtualization in use.
Comments