RSS
|
||||
 The Application Infrastructure Platform | ||||
|
By Nick Gall I have mixed feelings about this column. While I'm excited about the content, which captures much of what I've been groping toward over the past several years, I'm saddened because this will be my final column for a while. I have enjoyed writing it and appreciated all your feedback, but my position at the META Group requires my full attention. For my parting shot, I'd like to present my vision for an AIP (Application Infrastructure Platform).
But even as organizations demand application control on the server, many are confused about the proper application server infrastructure and jump from one dead-end approach, such as fat client, to another, like HTTP/HTML-centric Web servers. The Web: Right Client, Wrong Server The Web revolution has one thing right: Installing a different fat client front end for every application to be deployed to thousands of users is a waste of time. A universal client container that enables a variety of GUIs (built with different technologies, such as ActiveX, HTML and JavaBeans) to be deployed just in time, without complex installation procedures, is the way to go. But even if the Web adds up on the client side, it got the server side all wrong. A Web server coupled with Web development tools is a poor foundation for a scalable, transactional, reusable application server to be integrated with existing applications. The main problem is the severe limit in the kinds of services it affords to applications. HTTP session management and security services are about all they offer. An infrastructure is a set of services that applications invoke via interfaces. Despite vendor promises, there always will be a trade-off between high-level application infrastructure services, which reduce the amount of application code dealing with "plumbing" issues (i.e., code that has nothing to do with the business function being implemented), and low-level services, which actually work efficiently. Most application developers try to reconcile two conflicting goals: Implement a business process as richly and quickly as possible; and use infrastructure resources, such as CPU cycles and network bandwidth services, efficiently. But as they rarely have the time, skill or inclination to pursue the second goal, they buy into high-level infrastructure services to off-load as much plumbing code as possible--and there is a significant amount of such code when the components and resources that comprise an application (clients, servers and databases) are distributed on a network. Hence, there is an inherent notion of a "distributed interface" between distributed components. The Holy Grail has been a true "location-transparent" high-level interface between distributed components, which would allow the application to ignore whether two components linked by an interface were executing intraprocess, interprocess, across a LAN or across a WAN. RPCs and SQL data access via ODBC (tried, but neither achieved anything near true location transparency. Chasing the illusion of location transparency led developers to create applications that they saw as having a very clean, simple design--and that network analysts blamed for atrocious performance across the WAN.
|
|
|
|
Next-Generation TP Monitors: Are You Ready? September 1, 1997 Business Is Getting The Middleware Message November 1, 1997 Infrastructure Pattern Matching February 1, 1998 Information Everywhere And Not A Drop To Drink April 1, 1998 Privileges Of Application Integration Membership June 1, 1998 Corporate View By Brian Walsh On The Edge By Art Wittmann  Print This Page E-mail this URL |
 |
||||
The writing is on the wall for the "fat client." More organizations view their fourth-generation language-based desktop applications (PowerBuilder, Visual Basic) as legacy systems that must be scrapped or moved to the server using expensive Band-Aids like Citrix's WinFrame. The catalyst for this shift is clearly the Web, which presents the browser as a universal "thin client" container.
