WebServices dot org

An Intro to SOA and Virtualization

Well, there are in fact at least 3 distinct ways that you can use virtualization concepts in SOA, so I think that it would be good for me to give you a definition of those three.

Rich Seeley recently interviewed me for a SearchWebServices.com article on the first and most often mentioned type of virtualization I’ll introduce -- which is hardware virtualization. This is not a SOA specific thing. This is when you’re running many copies of the operating system within one physical hardware device so that you can get independence of those several virtual machines from each other -- from a configuration, app server and operating system point of view, but leveraging one piece of hardware to do that.

The second type of virtualization is virtual service end points. In a sense what you’re doing is creating a virtual location for your consumers to access in order to invoke the service when in fact you’re completely shielded from the actual end point of the service itself. So there is more disconnection between the consumer and the producer in that kind of virtual service end point. Again, I’ll tell you why you’d do something like that and what the pros and cons are on a future blog.

The third type is virtual services themselves: services that don’t actually exist -- you construct them without actually implementing them in a development tool. Again, this type is separate from the other two types I’ve just introduced and has its own reason(s) to exist. This is a powerful concept for managing the design and change cycles of SOA that I'll discuss soon.
So I hope you can get from this at least a basic idea of the three different kinds of virtualization you might be interested in with regards to SOA.

Hardware Virtualization

We certainly like this technology, especially in a SOA, as this can help us with deployment efficiencies and versioning of services. The more that we can isolate the configurations for all the individual services running, the better.

It would be ideal if I could share one server-class machine among let's say 10 different services. But if I tried to put them all on one operating system, I inherently have configuration challenges due to the co-location of the services on one box. This creates challenges when different teams want the optimal environment for their service implementations. In fact there are some times when they are just downright mutually exclusive.

That’s where virtualization of hardware comes in. I still get that one server box, but within it I set up 10 different operating system installs on one physical infrastructure, and I am able to independently manage all of those different machines each having its own configuration. Let’s say that one service provider is running on Windows 2003 and another is running on Linux. I can run both operating systems on one physical device, without having to try to figure out how to get my teams to give up the rwar on operating systems. This is a perfect example of how we can get lots of leverage from virtualization of the hardware.

There’s another cool capability of hardware virtualization when I deploy a new version of service.

In a typical deployment of service updates:

• I have to change the code

• I have to change the configuration sometimes

• I might have to run database updates and these activities may basically take my service down for what could be long periods of time.

Clearly, all of the above might be a problem for my consumers. I can’t always schedule my outage times based on when all of my end users are okay with that. I may have global consumers – or not even know all my consumers. How could I possibly make updates given that there’s no particular safe time for that change.

Virtualization allows me to create a new virtual environment for the new version of that service, to configure it appropriately and to flip a switch by bringing down almost instantaneously the virtual machine that ran “version 1” of the service, and bring up immediately “version 2”. Furthermore, what if this “version 2” deployment just blew up on me? Rather than try to figure out how to uninstall the new version, un-configure the system changes and roll back my database changes, I can immediately revert back to the previous version of the service, if a deployment challenge arises.

Obviously as an SOA Testing provider, we find customers are able to move forward with a lot more confidence by validating their deployments using automated testing in conjunction with virtualized hardware. If the new configuration or build fails the battery of tests in production, the test fails and they simply roll back to the previous configuration, and treat the next configuration as a virtualized test bed for further refinement.

Having an “assembly line” of “as-was,” “as-is” and “to-be” versions as virtual configurations goes a long way toward reducing downtime due to rolling out, or rolling back new functionality based on the success or failure of both conventional acceptance testing, and automated testing of those virtual instances.

So, virtualizing the hardware provides us with a number of great upsides. These are just a couple of them. I whole-heartedly recommend that you think about services living in their own virtual environment on top of servers so that they are much more easily deployed and maintained at least in that regard.

Virtual Endpoint

One of our SOA partners is Infravio, which is now a part of webMethods/SoftwareAG. As an example, these guys provide an ability to virtualize the access to a service, so that you create a looser coupling between your consumers and the service providers themselves. There are a number of upsides to this approach.

The first is: no one wants hard coded URLs from machine to machine within the client side of their applications. There is a lot of brittleness to creating such a tightly coupled system. As a service producer, I may need to start scaling up to multiple hardware devices or inter-clusters, or I may need to start creating geographically distributed servers to support the growing application consumption of my service over time. So, if my consumers become hard-wired into the actual location of my services, I create an inability to scale and adapt my service over time.

Virtualizing the access to a service thru an intermediary like Infravio gives me the ability to tell all the world to do UDDI lookup to my services, so instead of mapping to the actual service end points, the consumer can map to the intermediary.

The intermediary can then use runtime policy or infrastructure availability rules to determine which of the potential end points I actually deliver the request to. In doing this, I’m able to manage and model how I want my consumers to hit the services that I produce. I don’t have to provide unfettered access to all, I can actually put policy around how, how frequently, and when that access happens. I can even start to distribute it, such that consumers may not even realize that they are accessing the service now locally to their geography versus remotely last week.

As an SOA tester, I want this same level of flexibility in how we invoke and verify the behavioral and performance integrity of these services. By tying into UDDI repositories like Infravio, CentraSite, Systinet, etc. our SOA tests are dynamically pointed to the appropriate virtual service location, ensuring that the test workflow remains supported. This makes tests even more valuable and reusable, as they do not need to be re-wired for new locations as the systems are upgraded.

In addition, the service provider can specify a “test channel” or test version for their services, so a test can identify itself as such to the registry and be provided access to that specialized channel, in cases where simulated transactions may not cause the same effects as live transactions.

So, virtual endpoints are a great idea as you think about the scalability and the loose coupling we want in a SOA.

Virtualized Services

I don’t mean virtualizing access to services as I mentioned above, 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 blog on Virtualization in SOA has been valuable, and feel free to ask me for clarification or more commentary on this or any other topic.