In a recent Gartner Group research report, the analyst posits that within five years, all new development will be based on one of two virtual machine models: Sun's Java-based J2EE platform or Microsoft's .Net Common Language Runtime. Why the move away from native code development environments? This is a trend that most CIOs have seen before. Why did COBOL replace Assembler on the mainframe in the 70s? Why did tools like Fortran, Basic, and C++ replace Assembler on the PC in the early 80's? Because these languages virtualised the processor into a common machine type. The reason that developers and users flocked to Microsoft Windows in the 80s and 90s had less to do with the fact that Windows provided a GUI than it did with the fact that Windows virtualised the entire production environment (printers, screens, internal network access) by providing a standard interface to all of these computing assets. But giving developers a standard way to access machine resources didn't make it any easier to develop applications that accessed Internet resources. Sun's Java initiative and Microsoft's early Active Server Pages tools were both designed to make it easier for developers to create highly functional Web sites without having to resort to the native code GGI approach. As both of these strategies have matured, they've turned into virtual machine approaches for encapsulating the network just as Windows was designed to encapsulate the machine. Trend #2: SOAPing up your objects
Existing Web technologies like Java and Active Server Pages allow developers to create highly functional user-to-machine interactions. But when the Web server or application server has to consume back-end services, these systems still use proprietary object management systems like COM or CORBA. (We can argue for years whether CORBA is proprietary or not, but companies who've tried to make objects interoperate on two CORBA systems will tell you that it just doesn't work without significant tweaking.) This dependency makes it virtually impossible for machines from different companies -- or even machines in the same company with applications based on different object standards -- to interoperate at an object level. What companies need is a common object invocation model. That's what SOAP provides. Unfortunately, adding SOAP support to existing applications requires intimate knowledge of the SOAP protocol, akin to writing your own screen driver in Assembler (in the old days). But .Net and upcoming versions of the Java Development Kit (JDK) will have native support for SOAP as the default object invocation protocol. Once your developers begin using next-generation tools to develop systems that require one of the two prevailing virtual machine runtimes, they'll be able to publish and consume their objects and services using SOAP without having to develop the underlying plumbing. All that work is done automatically by the runtime. And you don't have to wait until other companies adopt the technology before you can begin realising the benefits. You can start getting the benefits of standards-based object invocation technology now. Getting benefits now
One of the biggest benefits of deploying Web services now is the ability to implement Internet standard, TCP/IP port-based security to eliminate dependencies on security issues created by using technologies like NetBIOS or RMI. For example, applications written on a Microsoft platform that uses DCOM (Distributed Component Object Model) require "holes" that have to be punched in the firewalls to allow NetBIOS packets to pass through. Maintaining these custom firewall configurations is a full-time job in many organisations, especially as new applications are developed or new versions of the operating system are deployed in production. I've worked with several companies in the last few months that are using Web services technology to get around the NetBIOS problem. For example, one company took their existing back-end, COM-based services tier and wrapped it as Web services using the SOAP toolkit. Then they rewrote their Web applications using ASP.Net and set them up to use these new back-end Web services instead of using DCOM to call the objects like the prior ASP applications did. Now the only open port between their application tier and services tier is the standard port 80. What makes these applications easy to develop and deploy is the additional functionality provided by the virtual machine models. You can develop new applications that support standards like SOAP using these new environments in less than half of the time it takes to develop them using the native code approach. Why? Because the virtual machine environments are built from the ground up to support Internet standards, so they're exposed in a natural, seamless manner. Over the next few months, many development shops will find out that the only way to reduce time to market and meet the requirements of Web-aware applications is to move rapidly toward adoption of one or both of the new virtual machine standards.
Have your say instantly in the Tech Update forum.
Find out what's where in the new Tech Update with our Guided Tour.
Let the editors know what you think in the Mailroom.
