![]() Application Switching: Looking Both Ways A third generation of solutions d oes true application switching, enabling developers to rewrite application GUIs in Web HTML or other GUI forms (Java or ActiveX, for example). The green screen itself won't appear on the user's desktop in HTML or any other form. Instead, a few host screens will be screen-scraped on the middle-tier application switch, and then be used to fill up a few fields on a Web form. Yet again, these solutions suffer from being too back-end specific. Most focus only on rehosting 3270 applications. So, if you wanted to build a single Web form that had data from a mainframe application via terminal emulation and data from an RDBMS on a Unix box, neither the Web-to-RDBMS or Web-to-3270 tools would be complete. Plus, there are many other ways to access mainframe data more efficiently than just screen-scraping 3270 data streams. We need direct DB2 access, CICS transaction access and options like MQSeries integration. And, there will be more opt ions for mainframe and other resource server data access that will have to be switched. We need more solutions that offer flexibility on the back-end connections. In fact, I think we'll see a tandem approach: One vendor will offer the application development tool. Another vendor (or group of vendors) will offer the back-end connectivity pieces and other application subsystems (middleware) that might be useful for the application developer. I'm encouraged toward this view by what some of the SNA-centric vendors are doing (Attachmate, for example, is offering more mainframe connectivity methods than just 3270). Microsoft also looks like it's thinking this way. Its BackOffice components, particularly SNA Server with its add-ons for DB2 and CICS in addition to 3270 access, are beginning to gel into an application-switching platform. Obviously, Microsoft has a Web server to offer as well as an RDBMS. More recently, its low-cost Microsoft Transaction Server, code-named Viper, highlights Microsoft's intere st in making the middle-tier server more stable and scalable than a typical Web-to- RDBMS gateway is today. It also will include a CICS transaction integration component, code-named Cedar, to enable higher-function mainframe integration. As application switching is integrated with a real transaction monitor, the middle-tier platform can take off--and not just for secondary add-on applications, but also for primary-use applications (including electronic commerce). But Microsoft won't necessarily own the application development environment. Its tools may be used, but they don't have to be. Assembling a variety of back-end resource connectivity options with a reliable application platform is a good combination. IBM has components that it, too, could gather into a productive application-switching platform. Front-End Connectivity: Not Just the Web Most current application-switching solutions, for better or worse, depend on the Web as the desktop deployment environment. More specifically, they depen d on HTML screens delivered over HTTP protocols. This won't cut it long term, but it certainly has provided a quick opening gambit for this three-tier style of computing. Longer term, HTTP/HTML will be primarily for publishing solutions. Heads-down data-entry solutions will be built in other ways. What other ways? Certainly lightweight RPC and transaction middleware like BEA Jolt and its brethren will be used more often. So will message-oriented middleware (MOM), particularly as Microsoft's "Falcon" MOM finally ships later in 1997. The Object Request Broker (ORB) world will likely be layered above Remote Procedure Call (RPC) and MOM mechanisms, including Microsoft's Distributed Common Object Model (currently a Microsoft RPC but later certainly incorporating Falcon and Microsoft Transaction Server), Internet Inter-ORB Protocol (championed by Netscape, Lotus and others), and the Common ORB Architecture, or CORBA, (with even more champions). While it's difficult to pick a winner now, it's likely that all of these will be useful options for front-end middleware choices. It will depend on the a pplications being developed. Another front-end access method to be enabled is e-mail. Why shouldn't we be able to e-mail database queries? Lotus Notes now has scripting language extensions into SAP R/3, PeopleSoft and MQSeries. It's not hard to imagine Simple Mail Transfer Protocol (SMTP) messaging taking its place as an alternate data delivery and even an interactive mechanism, particularly for offline-enabled desktops and more workflow-centric applications. Many publishing applications, including all the push-and-pull vendors I've bludgeoned in recent columns, represent yet another front-end delivery mechanism. It won't be only HTTP/HTML for the front-end, and Web-only application switch vendors need to recognize this before it's too late. The vendor that puts together these pieces with flexible front-end and back-end connectivity options, a robust middle-tier application server environment and good tools for ap plication development should have a brighter future than the current flash-in-the-pan Web-to-RDBMS offerings. Neither vendors nor users can afford to be caught in the Web. Bruce Robertson is a program director with the META Group's Global Networking Strategies service. He can be reached at Bruce.Robertson@metagroup.com. |
![]() |
by Patricia Schnaidt FreeWire by Bill Frezza Corporate View by Brian Walsh On The Wire by Bill Alderson and J. Sc ott Haugahl Updated March 25, 1997 |













