Virtualization up until this date has largely lived in the data center, where it has indeed saved significant hardware and configuration costs for a given set of servers. But this value has yet to extend to SOA, which is by nature much harder to replicate in this fashion.

In any decent-sized enterprise IT infrastructure, there are big assets like mainframes, as well as third-party systems, which can be costly and/or impossible to replicate through hardware virtualization. So these dependent technologies are often not available for developers and integrators to test and build against. Something needs to change to bring back that agility we expected from SOA.

A new type of Virtualization that is specific to SOA is Virtualized Services. I don’t mean virtualizing hardware, or 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.

Let's say for instance you can fully simulate 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, you virtualize 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 these discusssions on Virtualization in SOA have been valuable, and feel free to ask me for clarification or more commentary on this or any other topic.

You do not have flash or javascript support.

Average (2 votes)

Reply