[ Back to Index of Web Works ] part of George's Web Site

Related Web Works


http://www.activextra.com/news/news.cgi/n0924.html

[Image]

[Visit SunSoft]

[Image] October 14, 1996 [ActiveXpress.com--The Ultimate Website for the ActiveX Community] [Impact] [Image] [Image] JAVA BEANS' LEAD ENGINEER SPEAKS OUT -- JavaSoft's architecture vs. Microsoft's ActiveX

[Image] By Deborah Gage, Computer Reseller News Online

[Image] JavaSoft this month published the first public specification of Java Beans, a component architecture for Java that rivals Microsoft Corp.'s ActiveX. Java Beans are reusable components that hook together and can run inside Java applets, Netscape browsers, OpenDoc containers such as ClarisWorks, and OLE/ActiveX containers such as Microsoft Word and Internet Explorer. A developer could create an application that retrieves interest rate data and draws charts. A bean that retrieves account data could be added and the three would automatically interact.

Microsoft has promised to publish the specification for ActiveX to make it an open, cross-platform standard like Java, but JavaSoft believes that is impossible. Java Beans is a core Java API, which means Microsoft will be forced to support through the Java Virtual Machine to be embedded in Windows. CRN Senior Editor Deborah Gage spoke with Larry Cable, JavaSoft's lead engineer on Java Beans.

"Microsoft is competing with us on ActiveX. If you look at the direction they're taking [with] ActiveX, Microsoft is simplifying the OLE APIs to make the controls simpler. Although OLE was originally designed to support Word and Excel, not too many people are willing to pay the cost of that complexity.

"Microsoft is competing on ActiveX, but they are also participating on Java Beans because they have to-they also have a lot of very relevant experience they can bring to the Java Beans design.

"That said, I think they are going to have a hard job in making ActiveX truly platform independent. Right now it is not only platform-dependent, but instruction-set architecture-dependent. If I develop an ActiveX control today to place in a Web page, I'm not familiar with any facilities to discern what processor I compiled the ActiveX control for. Windows 95 runs only on Intel and NT runs on some others . . . but that's a platform dependency we don't have. They need to change the HTML tags and they must be aware of this. What you're doing is loading compiled code over the network, and it doesn't work if you've got a heterogeneous set of processors.

"Beyond that . . . there's a very close relationship between the Win32 APIs and the facilities you find in ActiveX. I'm not by any means an ActiveX developer . . .but how can they possibly expect to make ActiveX controls portable to Unix and Mac? They don't have access to the APIs and facilities you find on the native Windows platform. OLE and COM are relatively free of platform dependencies, so you can manage to port those, but once you've got them there, what are you going to do? The moment you start calling Mac and Unix APIs, you have a problem. The Win32 API doesn't exist on Unix or Mac. SunSoft spent a huge amount of effort trying to emulate the Win16 API on Unix, and I know indirectly from those people what an enormous task that is. And I can't imagine Microsoft would be motivated to enable Windows apps to run on Unix.

"What do you have to do to make ActiveX controls on Unix or Mac useful? It's like having the ignition key to a car that has no wheels on it-you can start the engine, but you're not going anywhere without wheels. Even if Microsoft does make ActiveX a public, open spec and gives it to an appropriate standards body, and obviously Sun has publicly stated we'll participate in any efforts to work on that, it's questionable what the value of that is.

"Once you're on the system, if you haven't got a portable set of facilities to call the controls, they're not portable. They're portable from one Unix to another or one Mac to another, but you can't embed an ActiveX control into a Web page from that Mac onto a Windows 95 system and have it run. If a control wants to draw even one pixel on a screen it has to access the Windows graphics APIs. Those APIs don't exist on the Mac. Maybe they have a portablility layer. But they certainly don't exist on Unix.

"The moment you try to access any of the system services-like the file system-you have to go to the system APIs, and all the systems are pretty much different. Maybe you could have a purely computational control-for example, an ActiveX that calculates pi to several hundred decimal places-because that happens at the source code level.

"I think if you look back at the industry, there's a lot of value in taking the technology and turning it into a standard and being the leader with that standard. It is a really powerful tool for establishing your technology as preeminent in the marketplace. Given that, I have to question what Microsoft's motivation is for saying they're going to publish ActiveX."[Image]

[menu bar]


[ Back to Index of Web Works | Top ]