Catching Up On the Server Side
Horses for Courses
Fat and Rich—Furthering the Lead
The Microsoft Mobility Mission
Forms, Clients, and Developer Kudos
End-User Productivity Really Does Matter
James Governor
September 24, 2002
IT managers must match horses to courses. The needs of a data-entry clerk tapping away eight hours a day in a call center are radically different from those of a salesperson who wants to update expenses once a week over a dial-up connection. But supporting multiple access models certainly makes development more difficult.
Portal developers like BEA, Computer Associates, IBM, Plumtree, and Sybase—who have all claimed their software is the "desktop of the future"—are currently very weak on the client-side in comparison to Microsoft-based clients. All of these vendors are, in one way or another, pursuing strategies to overcome the weakness of their clients. The trouble however is they all have different answers to the problem—unlike Microsoft which has one answer: use Windows-based rich clients. This is perhaps unfair to the Anyone But Microsoft (ABM) club—after all, Microsoft offers a number of different rich clients, not just one. But, and we shall we return to this below, this is where the Visual Studio .NET advantage comes in. Microsoft is pursuing a strategy that allows developers to write-once, then deploy to any Microsoft client. For now Java IDEs offer no equivalent capability. That is the problem with openness—too many darned choices!
Portal vendors are working to develop client-side technologies to improve the user experience, in the shape of new as yet un-standardized technologies such as portlets, or what IBM is now calling edgelets. Great names for both technologies, but when it comes to a self-contained rich user experience—where's the beef?
IBM's WebSphere Application Server and WebSphere Studio provide all the functionality a customer would need to build transactional applications. But rich client apps? IBM can't go there and it knows it.
BEA, another vendor determined to succeed in the portal space, has implicitly admitted the same problem by introducing the concept of a "push browser." The idea is that a push browser would connect to a networked app without requiring "refreshes" to update fields and content. BEA however has yet to offer any details as to how this would work in practice—which browser or standard would underpin this push model are questions that have yet to be answered. Obtaining sufficient consensus to offer a standards-based push browser is even farther off. Who could drive this initiative through? The Java Community Process is notoriously slow. Microsoft and IBM have recently been specifying and establishing standards at a furious pace. But there is no way Microsoft is going to work with IBM around standards-based rich clients. The Microsoft rich client standard is de facto—it's called Windows.
 |
|
|
|
|
|
|
 |
|
|
|
|
|
||||||||||||