Rourke on SOA

Yesterday Matt Quinn of TIBCO Software, Inc. talked about Service Virtualization at the Gartner Application Integration and Web Services conference in Orlando. Matt started his presentation by saying that Service Virtualization is:

Functionality designed to reduce complexity of communication, location and control as service networks increase in size.

Service Virtualization, a key feature of TIBCO ActiveMatrix Service Grid, is a technology meant to help companies deal with the complexity that comes with doing large-scale heterogeneous SOA. Period. Matt spent some time at the beginning introducing some of the problems companies with large service networks are beginning to face, including communications management and service scaling challenges. Matt then talked about how TIBCO’s approach to Service Virtualization helps to solve these problems.

So, what is service virtualization? If you deploy services using ActiveMatrix Service Grid (AMSG) then those services can be invoked by other AMSG services via a single line of code. That line of code doesn’t need to change, regardless of where the service is, what language it’s written in, and how it is load balanced. Further, any or all of those details can be changed between one invocation and the next without downtime or a loss of service. Once a service is “on the Service Virtualization Platform (SVP)” or “on the grid” (which rolls off the tongue easier?) it can be discovered by other grid services via the Asset Manager or by non-grid services via a UDDI registry. Either way, the invoking service doesn’t need or have any knowledge of where the service is or how it is implemented.

This approach even helps with service versioning, a major pain point for early adopters of SOA. A proxy that translates a service call from the old version’s interface to the new version’s interface isn’t a great solution when you need performance. At least not when a proxy means SOAP serialization and de-serialization. Enter AMSG, which allows you put a “version proxy” in front of new services without that proxy performance penalty.

Matt spent some time at the end of his presentation talking about service scaling and dynamic provisioning of services. Looking back, both runtime UDDI and ESB technologies promised us the ability to truly decouple service invocations from their endpoints. Despite the hype, both failed to deliver on this promise to the point where they could enable dynamic service provisioning.

With respect to service scaling, the key difference between using AMSG and using an app-server based technology is the fact that your systems administrators — independent of the developers — can choose how best to deploy your services and can change that deployment topology dynamically. For example, if two services are generating the bulk of the load on your application you can deploy extra instances of those two services without deploying duplicate instances of all the other services that make up the application. Further, you can do all this without regard for what language those services are written in. You scale all services using the same mechanisms.

There has been talk about dynamically provisioned services for years now. The problem is that even ESBs bind the service invocation too tightly to the service implementation. Reality never lived up to the hype. Service virtualization finally delivers the goods. Deploying extra instances of a service deployed on the ActveMatrix Service Grid (the SVP, if you will) can be done easily via JMX invocations. As soon as that new service instance is up and running the grid discovers it and starts to share load. How do you know when to deploy those extra instances? Load information is also available in real time as events on the grid, and those events can be monitored with CEP software that can take action when it sees the potential for SLA violations.

So, Service Virtualization helps mitigate the complexity that comes from wholesale adoption of services. It does this by truly decoupling the service invocation from the service implementation regardless of language and without the performance implications of a proxy-based (as used in an ESB) approach. The decoupling is so complete that it put deployment decisions in the hands of systems engineers and enables dynamic service provisioning. Further, AMSG even decouples deployment, management, and monitoring from the development language used which allows for scaling to be done using a single methodology. The feedback from Gartner attendees was very positive — there is a definite need for this technology out there.

(Disclaimer: I am employed by TIBCO Software, Inc. , the company referred to in this posting. Further, this article was written and published without the approval or explicit knowledge of TIBCO Software, Inc. )