Last but not least of the three types of virtualization you might want to consider for SOA is
Virtualized Services. I don’t mean virtualizing access to services as I mentioned in a previous blog, I mean simulating the service’s existence, without actually creating it. Now, how can that be important?
Virtualized Services are especially important to achieving the dream of agile SOA testing: shorter, iterative, requirement-driven test cycles, with testing happening every step of the way. Why? Because if you want to test earlier, you will need to test incomplete components, or “in progress” integrations. SOA applications are particularly prone to change, so if you have to wait for a finished app to test, that becomes a bottleneck to agility.
For instance our SOA testing product incorporates this approach. LISA has the ability to analyze a WSDL and to generate by itself the actual service endpoint. What this means is that before your development group has even shown up to build the actual service, our product virtualizes the service and creates a simulated version of the real thing (which doesn’t exist yet) – such that your consumers can invoke this service as if it already existed.
Now, in a simplistic world this can be done in a variety of ways with mock objects, or with other methods that provide a specific hard-coded response whenever they are stimulated. But in reality you are going to need a fairly dynamic service, even in a simulation. You can’t really spit back the same silly response to every single request, because your consumers are going to need a lot more richness and variability in the way that the service responds.
So, the ideal approach to SOA testing allows you to not only virtualize the service but to make the actual behavior of the service dynamic, i.e.: reading from database tables or spread sheets for values, or doing look-ups based on input requests. While it sounds like you are actually building the service (which in some ways you are), in reality you are providing just enough very high productivity logic within the service that you have virtualized so that the consumers get what they need without having to wait for the actual service to be completely developed and tested.
In fact, there’s a great “test first” model here, where developers of the actual service will know they’re done when tests written against the virtualized service work on the actual service. The consumers are confident that they will get what they need from the actual service when the virtualized service has been sufficiently executed against. And
with that virtualized service testing out of they way, you can now point the actual service consumer to the actual service producer, and therefore, likely have a much more successful integration from the very first touch.
I hope this series on Virtualization in SOA has been valuable, and feel free to ask me for clarification or more commentary on this or any other topic.
Previous Virtualization Posts in this series:
Labels: virtual service, virtualization, virtualized services
