Application Switching: Looking Both Ways
By Bruce Robertson
Recent examples of three-tier computing architectures focus on Web-enabling traditional two-tier applications (HTML-to-relational database management systems, for example), but that's only the tip of the three-tier iceberg. The Web may be an important component of application solutions because it introduces the typical three-tier
architecture pieces (protocols, user interface and container and document format), but other application and network environments can benefit from three-tier application switching.
 The "Webification" of Applications
For many applications, there w
ill be a middle-tier application-processing server. For a single application like SAP R/3, this brings many benefits (see
"Those Application Networking Nightmares,"
. First, by off-loading processing from a back-end server (such as an RDBMS or a mainframe), the server can service more users or handle transactions more efficiently.
Second, by off-loading the front-end client, the desktop can perform other tasks more efficiently (remember, thin is good). Third, by partitioning network traffic and using different middleware (and sometimes even network protocols) for the back-end and front-end connectivity problems, enterprise networkability can be greatly enhanced.
But my earlier points were about a single application system. The next generation of this three-tier technique will involve a variety of applications for both hosts and clients. Many corporations are searching for more efficient ways to offer additional task-specific application access to data normall
y visible only within existing large-scale application systems like SAP R/3 or mainframe systems. They want to enable employee self-service for traditional human resources applications, such as PeopleSoft. They want to mix the data from two different application
systems into a new application targeted to various users. They want to enable application and data integration.
This more mellifluous application integration might well be called application switching. The switch, similar to a messaging backbone switch, translates between two different systems but preserves fidelity. The switch functions in the middle--between a server that talks one way and a client that talks another. The application switch has two faces: back and front.
This application-switching approach is heralded by the massive Webification of applications we're seeing. Every application system is adding a Web client interface as an option, again, typically for different task-centric users than their legacy application-client solutions
. Like ducks, applications need webbed feet to swim on the Internet or intranet.
But there are limitations to Webification. Web clients can't offer the full functionality of normal Windows or other OS-centric client applications. We're waiting on Java and ActiveX to enhance those apps (beyond HTML and simple scripting), and on more middleware options (beyond HTTP) to enhance reliability and performance.
Certainly, we'll see a lot of development of this sort of application-switching platform. Today's products are often Web- and RDBMS-centric. These products connect Web browsers to RDBMSes. That's not enough. We need solutions that provide high performance and high reliability through the switch. We need solutions that integrate other back ends and offer more front ends too.
Back-End Connectivity: Not Just RDBMSes
Consider the back-end problem first. Internet buzz has been mostly in the Web-to-RDBMS area. Products abound, but these are only point solutions for those hastening to reveal spe
cific data to Web users. They may not be optimized to handle other data sources.
More recent buzz has been around mainframe application solutions getting Webified. First, there was the 3270-to-HTML on-the-fly terminal-emulation hype. This, however, was short-lived, a
s users discovered problems with putting session-oriented traffic over HTTP, a session-less protocol. Second-generation solutions (such as IBM Host-On-Demand) are Java emulators (tn3270 or proprietary) that don't use HTTP to communicate to the gateway. They recreate the green screen as an applet, and the middle-tier gateway doesn't perform any serious application switching.
|
REPORTS
ANALYTICS
Follow 
