Rollout: WebLogic Server Virtual Edition, LiquidVM and Liquid Operations Control

If you think OSes are becoming entirely too bloated, BEA Systems has a radical solution: ditch them entirely. Its WebLogic Server Virtual Edition, intended for virtualized servers that are part of a SOA infrastructure, runs directly on top of VMWare, no Windows or Linux necessary.

Losing the operating system has several benefits. Many OS services are already duplicated by Java or the hypervisor, and BEA estimates that cutting the OS can reduce consumption of system resources like memory and CPU cycles by 25% to 50%. It also simplifies management, as WLS-VE knows that it's being virtualized and so can more easily map software processes to the hardware it's running on. Performance can improve, as a complete OS doesn't have to be loaded whenever a VM is started.

Still, though WLS-VE shipped in July, its Liquid Operations Control (LOC) management system won't be available until December. Performance claims haven't yet been proved and will depend on using hardware with virtualization support baked in—without it, VMware simply takes the place of the OS.

Moreover, WLS-VE currently supports only 32-bit x86 applications: Though it can run on 64-bit hardware, each VM behaves like a 32-bit machine. And, some customers will miss OS features that BEA has cut in the name of efficiency, especially support for local disk drives.BEA is taking a unique path here: Java VM competitors Microsoft, IBM and Sun are all retaining their OSes. Even SOA platform vendors like SAP and TIBCO that don't make OSes see little reason to scrap this layer. However, all aim to simplify management of VMs in a SOA. Everyone agrees that SOA and virtualization belong together, as both aim to increase IT's flexibility: SOA by building applications out of reusable services that can easily be mashed together in new ways, virtualization by making services less dependent on an underlying computing platform. If a service is reused in a SOA, virtualization should let IT managers quickly, or even automatically, allocate hardware as needed.

Virtually An OS

BEA's approach to SOA virtualization is aided by the dominance of Java, which has always been partly virtualized. Because Java apps are designed to be portable across different platforms, they run inside a VM that isolates them from the underlying environment. Just as a client-side Java app doesn't care whether it's on Internet Explorer or Firefox, the server-side Java apps in SOA don't care whether they're on Windows, Solaris or Linux.

Because a Java VM is concerned entirely with running Java code, it duplicates some higher-level OS functions, such as memory allocation as each Java app runs in its own memory space, something that also helps with security, but not device drivers or anything that affects hardware.

Hypervisors like those from VMware approach virtualization from the opposite direction: They operate underneath the OS, appearing to it as hardware (see figure, at right) To achieve this, a hypervisor must perform many of the same tasks as an OS, duplicating lower-level functions so multiple operating systems can run concurrently. The end result: The OS in a virtualized Java server is squeezed from both sides, using an increasing share of system resources but with relatively little to do.

Though the OS has a reduced role, it is still responsible for several critical functions, including networking, I/O, thread scheduling and file storage. BEA has added these to its JRockit Java VM, producing a Java implementation that can run directly on a hypervisor. BEA has also dropped some OS features that it thinks aren't really needed in modern enterprise servers, including the GUI and support for some local devices, such as printers. The one that users are most likely to miss is storage: Instead of its own hard drive, the server must use network-attached storage; SAN support is planned.

BEA's souped-up version of Java, called LiquidVM, is able to run most JRockit software unmodified. The main exception is anything that uses JNS (Java Native Interface), a method for calling functions within the underlying OS, usually Linux. JNI can't be implemented because there is no underlying OS. At present, LiquidVM is available only as part of WLS-VE, but BEA plans to use it as the basis of other products, including its AquaLogic service bus, and is considering licensing the technology to other vendors building virtual appliances.

Hard Ware

LiquidVM is still very much a first-generation product, meaning initial applications will likely be limited. While servers are moving to 64-bits, it currently supports only 32-bit applications, limiting each VM to 3.8 GB of addressable memory space. And because it's designed to take advantage of hardware-assisted virtualization technology in x86 chips, it doesn't support other hardware platforms that JRockit is compatible with, including Itanium and SPARC.The only hypervisor that LiquidVM currently runs on is VMware ESX, though others are planned in response to customer demand. A new version, due in late 2007, will add support for XenSource's implementation of Xen, while the revision after that will support Microsoft's Viridian hypervisor. Running on new hypervisors is simply a matter of testing and support, as all are emulating the same underlying hardware. BEA says that it LiquidVM can also run on bare metal, though without the flexibility that virtualization adds.LiquidVM's most direct competitor is Linux, increasingly promoted by BEA competitors IBM and Sun as a platform for Java. Neither plans to abandon the OS, though both are developing management tools that aim to simplify virtualization in a SOA.

Microsoft is following much the same strategy, though based on .Net and Windows rather than Java and Linux. If BEA enters the virtual appliance market, it will face more competition from Linux, whose open-source nature means vendors can already discard components they don't need.

Andy Dornan is a senior technology editor for Network Computing. Write to him at [email protected].