SOA's Perfect Mate?

They're two of today's hottest technologies, and for good reason. Server virtualization provides cost savings on top of flexibility, while a service-oriented architecture affords application reuse and fast response to business needs. But the benefits of combining them can be less obvious.

SOA helps with virtualization by breaking applications into smaller chunks that are more easily spread across multiple servers or CPUs, even off-loaded to outside service providers. Through common runtimes like Java and XML standards, SOA shields APIs from the underlying hardware or operating system. In return, virtualization simplifies SOA by easing provisioning of new hardware resources.

They're the ultimate power couple. Too bad so many obstacles stand in the way of togetherness. Virtualization management apps have communication issues when it comes to SOA, while their Web services equivalents aren't good at setting boundaries for virtual machines. But just because we have a way to go before this marriage of agility is a done deal doesn't mean organizations investing in SOA, virtualization, or both shouldn't anticipate the matchup when making buying decisions. Big application vendors, including BEA Systems, IBM, Microsoft, Red Hat, and Sun Microsystems, have SOA/virtualization synergy on their minds, and so should you.

THE REPORT: SOA Simplicity

Enterprises looking to link their SOA and virtualization initiatives must streamline. Here's how

informationweekreports.com

MADE IN HEAVEN

Server virtualization makes most IT pros think consolidation, and it's easy to see why: One machine taking over tasks that previously required two or four or 10 equals powerful cost savings, both in hardware and in management, heating, and cooling. But consolidation is only the first step. The greatest benefit of virtualization will come from increased flexibility realized by chopping up servers into smaller units of resources like CPUs, memory, and disk space, which are then pooled and allocated to apps on demand.

What virtualization does for hardware, SOA does for software. Programmers need no longer develop each application separately; SOA lets them build apps from simple services that can be used over and over. Those programmers are, increasingly, business analysts who use model-based development environments and never have to write a line of code.

Problem is, the reuse that makes application development much faster also may strain the underlying hardware. When a service is reused, the server it runs on demands a lot more computing capacity.

Virtualization is an obvious solution, simplifying SOA by easing provisioning of new hardware resources. Unfortunately, obstacles abound. SOA's variable loads require server allocations that vary from a small fraction of one server's capabilities to the need for many servers to provide the service. On the virtualization side, most of the industry is still at the consolidation stage, focused on splitting a single server among multiple operating systems. Pooling the resources of multiple servers requires moving in the opposite direction, toward something closer to grid computing or clustering than what VMware and Xen offer today.A truly agile infrastructure also needs VMs that can move quickly among servers, which entails the use of virtual storage and virtual networks. Most important, management capability must be integrated throughout the whole software stack. Virtualization vendors offer management tools that make VMs easier to set up and tear down, but they're not yet integrated with application management and SOA governance.

When it comes to SOA, virtualization can help in two main categories: middleware and the underlying services. Most products broadly classed as SOA fall into the first group, including enterprise service bus, management, governance, and security software. However, the greatest flexibility gains in SOA virtualization come from the second category, which includes Java and .Net servers as well as connectors to legacy platforms. This is both because services use more computing resources than middleware and because the demand for particular services is more likely to fluctuate.

(click image for larger view)

NOT QUITE A VIRTUAL SLAM DUNK

Application platforms such as those from BEA, IBM, Microsoft, Red Hat, and Sun ought to be relatively easy to virtualize. First, they're already partly virtualized, meaning they run inside a Java or .Net virtual machine that isolates apps from the underlying operating system. This was done to simplify development by making applications more portable and secure, but it also should aid with agility. In addition, all these major application platform vendors, except BEA, sell OS-level virtualization technology (see table, p. 35), so they're in a position to help make the two work together better.

Combining OS-level virtualization with Java VMs is essentially a management challenge. At present, virtual instances of operating systems are created and managed by software that's bundled with hypervisors from vendors such as VMware and XenSource. This hypervisor-level software is good at understanding how a virtual server's resources relate to physical hardware, but it can't see inside applications.Conversely, SOA and Web services management tools can't see outside an application platform. Most provide management agents that run inside Java VMs, but they don't know whether the underlying server is virtualized or not.

The biggest player in Java is IBM, through its WebSphere line. IBM has offered virtualization in mainframes for 40 years and still pitches its System i and System p as platforms for Java apps. Both have full OS virtualization built in to their AIX and i5/OS operating systems, respectively, and can support Web services either by running Linux or Windows inside a virtual machine or directly through Java VMs. This affords a lot of flexibility, but the need to standardize on IBM proprietary hardware and software will put off many enterprises.

IBM doesn't have its own hypervisor for standard x86 servers, but it does contribute to the Xen open source project and partners with hypervisor vendors, including VMware. Its main virtualization offering here is WebSphere Extended Deployment (XD), which provides for clustering multiple Java VMs. Administrators can set internal service-level agreements for specific services; the system then will configure Java VMs based on demand by creating new virtual instances and prioritizing the resources available to each. This capability isn't limited to IBM products, so WebSphere XD will work with most Java VMs and operating systems. However, it's limited to Java apps because it doesn't reach down into the hypervisor layer.

Windows servers running .Net are a part of most Web services installations, and Microsoft has big plans in both SOA and virtualization. In SOA, Microsoft last year announced Oslo, a long-term strategy aimed at simplifying application development by replacing code with a Visio-style model. Microsoft's virtualization plans are much closer to fruition. It already offers Virtual Server, which allows users to run older versions of Windows Server on top of the latest version, and plans to ship in the third quarter its Hyper-V hypervisor as both a component of Windows Server 2008 and a standalone product. There's little integration between the two--mostly because Oslo is still vaporware and may not ship before the end of the decade.

(click image for larger view)

Red Hat has become an important Java player thanks to its acquisition of JBoss, which the company is now extending up the stack from the platform into SOA middleware. Because it's free and open source, JBoss has spread rapidly, even though most users aren't paying Red Hat customers. "We're in as many enterprises as BEA and IBM," says Shaun Connolly, VP of product management for JBoss at Red Hat.

Red Hat also baked the Xen hypervisor into its Red Hat Enterprise Linux, in order to offer a complete stack--albeit one that must run RHEL and so doesn't truly compete with XenSource and VMware. Red Hat says that most of the demand for virtualized services is in testing scenarios. Because Web services are relatively easy to create and can have a major impact on other parts of a hardware or software infrastructure, testing them in virtual environments is necessary to ensure compliance with industry standards and internal policies.

Sun's Solaris has its own built-in virtualization technology, called Containers. This is really application virtualization: Only one copy of the operating system runs, but apps are still separated. Applications do need to be able to run on Solaris, though the company offers a compatibility layer that emulates Linux APIs.

Sun also is entering the hypervisor market with xVM, open source management software technology that it hopes can reduce what Sun calls "VM sprawl," the growth of unmanaged--and sometimes entirely unknown--virtual machines throughout an enterprise. Though built on Xen, xVM includes failover and predictive self-healing technology that can isolate faulty hardware components without affecting individual VMs. By shipping a combo of Xen and management software, Sun is competing directly with specialist Xen vendors XenSource and Virtual Iron Software, and with VMware. Most of the non-Xen technology in xVM is ported from Solaris, though it doesn't require Solaris or any other Sun hardware or software.

THE SUPERFLUOUS OS

BEA doesn't sell a hypervisor, but so far it's taken app server virtualization the furthest with its WebLogic Server Virtual Edition (WLS-VE). Although BEA's impending acquisition by Oracle means plans are likely to change, WebLogic fills an important gap in Oracle's product line and was a major motivation for the acquisition. WLS-VE can run directly on top of VMware, with no need for an operating system at all. The theory is that because Java apps already run in a Java VM, the OS is largely superfluous. The hypervisor includes lower-level OS functionality such as device drivers, while BEA has added higher-level functions such as I/O and file storage into a new version of the JRockit Java VM that it calls LiquidVM.BEA says that cutting out the operating system can boost performance by up to 50% by saving on system resources. However, the company couldn't put us in touch with any customer that might verify its claims, and competitors point out that system resources, including CPU power, memory, and disk, are relatively cheap and getting cheaper all the time. The real benefits ought to be in management, as removing the OS should simplify the creation and movement of Java apps while making it easier to create a management system that has a full view, from hypervisor to app layer.

Unfortunately, claims of simplified management are hard to quantify because BEA's Liquid Operations Control, or LOC, management software hasn't yet shipped. Originally scheduled for the third quarter of last year, it's now due by March. At present, the management software that controls outside applications also controls apps within LiquidVM, while VMware handles the virtual machines. "Management frameworks are basically alarm generators," says Guy Churchward, VP and general manager of WebLogic products at BEA. "If something crosses a threshold, it notifies an administrator. There's no feedback loop."

LOC is intended to change that by giving LiquidVM a dedicated platform that can start and stop both VMs and the processes within them, as well as keep track of which applications are running where. Because LiquidVM will coexist with other Java servers, it's also intended to control applications on physical servers that support the Java Management Extensions spec and, perhaps most important, map service dependencies, knowing that increased use of a service in one VM may require increased resources dedicated to others.

THE REPORT: Virtualization Smackdown

VMware is sitting pretty, with dominant market share and loads of cash. But can it last?

informationweekreports.com

Most service-oriented architectures keep track of application requirements and dependencies through the registry, an XML database included in SOA governance software. Though BEA sells a SOA governance product, Liquid Operations Control can't yet retrieve information from it. Administrators need to input parameters about different services' requirements and dependencies, which could duplicate some work. BEA says it's looking at integration with its registry product, which is based on technology licensed from HP Systinet, though as yet no firm plans have been announced. Hewlett-Packard last week expanded its Governance Interoperability Framework program, which aims to forge better links between Systinet and other vendors' products, but so far these are only in the SOA and enterprise Web 2.0 space.

LOC can act on information provided by AmberPoint's SOA management software, which BEA resells through an OEM agreement. However, the AmberPoint alliance is unlikely to survive BEA's takeover by Oracle, as Oracle has its own management product, Oracle Enterprise Manager. LOC will likely be integrated with this.The LiquidVM platform fills an important hole in Oracle's portfolio, giving Oracle a way to compete head-on with OS vendors. BEA's plan is to extend LiquidVM to its other applications, with editions of its WebLogic Portal and AquaLogic Service Bus shipping without operating systems at the same time as Liquid Operations Control. The acquisition likely means that LiquidVM will be used for virtual editions of Oracle's products, too.

At present, LiquidVM works only with VMware, but BEA says it plans to support Xen with a new release at the same time as LOC ships, and Hyper-V later in 2008. Oracle released a Xen-based virtualization product in November, so making LiquidVM work with Xen could be a top priority. Tying the two together exclusively, however, would negate one of LiquidVM's greatest selling points--that it can work with VMware, still by far the most popular hypervisor.

GIFT REGISTRIES

The registry doesn't have to be tied to an application platform, so standalone SOA governance vendors also could simplify Web service virtualization. The main player here is now Software AG, which bought competitor WebMethods last year. Software AG is merging WebMethods' Infravio registry with CentraSite, its own registry co-developed with Fujitsu. Rather than work directly with virtualization management, Software AG aims to expand the registry into a full configuration management database that can track all IT infrastructure, not just Web services, and share information with the main network management frameworks. "That's part of the reason we collaborated with Fujitsu on CentraSite," says Miko Matsumura, deputy CTO at Software AG.

VMware has very successfully promoted the concept of virtual appliances, which in some ways look like the opposite of SOA: Rather than breaking applications into small parts that can be rebuilt into new apps, a virtual appliance bundles an application with an operating system, usually a custom version of Linux, so that minimal configuration is necessary. But the two concepts can coexist happily. For example, in the past year, SOA security gateway vendors Vordel and Layer 7 Technologies have begun to ship their products as virtual appliances, a dramatic change given that security gateways usually are provided as hardware.

SOA security gateways began as XML firewalls, and this is still their most popular function. Like standard network firewalls, they are sold usually as physical boxes, often using dedicated XML acceleration chips. The shift to virtual appliances is driven partly by an aggressive XML strategy from Intel, which started promoting software XML processing as a way to boost demand for its general-purpose CPUs but in December actually entered the enterprise XML market itself, competing directly with some of its appliance-builder customers. However, the shift also is driven by the flexibility inherent in virtualization.Vordel and Layer 7 both say their virtual appliance editions were aimed initially at testing, yet some customers already use them in production environments. Both vendors expect this trend to grow. Compared with hardware appliances, virtual appliances are easier to install and manage, with server resources dedicated to the VM as required. For example, Layer 7 partner Sun is promoting the concept of on-demand security, in which security services are applied as needed from a virtual appliance.

The theory is that, because Web services are relatively easy to develop, they won't always be built by IT and may run afoul of enterprise security policies. Security gateways provide a way to contain such rogue services without necessarily harming functionality. "You can use the security gateway to buffer a service from its client," says Kevin Schmidt, director for SOA products at Sun. "Virtualizing the gateway becomes an issue of performance and manageability."

The Match Game
All Web services platform vendors have virtualization offerings, though most depend on using the same vendor's OS

FABRICATING APPS

For a truly agile infrastructure, virtualization must enable IT to spread an application across multiple servers, not just split a single server into several VMs. This is an even tougher nut to crack than standard server virtualization, however, because most apps today are fairly linear and can't easily separate their processing into multiple parallel operations. Developers are working to make apps parallel for multicore CPUs, but clustered servers pose additional bandwidth and latency challenges. For example, multiple cores within a single server can communicate with one another quickly and access common memory, but multiple servers in a cluster need to rely on networks, which are much slower.

For this reason, most approaches to clustered Web services don't try to break services into parallel chunks. Instead, application fabrics from vendors like Appistry and DataSynapse install an app on multiple servers and load-balance across them. This works well for most SOA traffic, as Web services usually involve responding to multiple user requests, which can easily be spread across several servers.For flexibility, all applications need to be installed on every server in the cluster, though in a large cluster with multiple apps they won't all be running at all times. Fabric management software can then adjust the capacity of each server automatically, based on both demand and parameters set by the network administrator. Rather than a separate layer, like a hypervisor, management software runs alongside apps, so it needs to be written to support each platform or operating system on which it will run.

In addition to IBM's WebSphere XD, two startups have launched fabric products. DataSynapse's FabricServer works with most Microsoft and Java applications, with support for in-house apps via common Java VMs and Microsoft's .Net. The product also works with VMware, enabling it to simulate true hypervisor-based virtualization across multiple servers. In this case, the hypervisor and each OS image would need to be installed on every server, with the DataSynapse software splitting capacity among operating systems the same way it does among applications.

Competitor Appistry supports applications written to most common Java and .Net VMs as well as Spring, a popular open source Java framework. Its EAF software also gives Java and .Net apps an optional clustering API, letting them access the fabric's features directly.

For now, fabrics look like a good choice for enterprises that need to scale applications out. But even fabrics don't tie into SOA management and registries, instead relying on their own load-balancing algorithms to allocate capacity. Software licensing also could get expensive, as every OS or application platform will need to be licensed for every server on which it may run.

For organizations looking to implement SOA and virtualization in a way that makes them as compatible as possible, for now we recommend following SOA's own design philosophy of loose coupling. With no standards for running Web services in virtual machines, and even proprietary systems still immature, these two seem poised for a long courtship. But keep an eye on developments so you'll be ready to jump in when the relationship is finally consummated.0